Updating Data Substacks

Richard Gaskin ambassador at fourthworld.com
Fri Jul 12 03:17:01 EDT 2002


Dan Shafer asks:

>> Good) Keep your data separate from the UI.  This way you can update the UI
>> independently of the data.
> 
> Thanks for the fast reply, Scott.
> 
> But this would require storing it in a text file and managing all the
> data manipulation stuff or alternatively using a database, right? If
> I have to do those things to keep data from being munged when I
> upgrade the app, I might just as well use a conventional programming
> environment! Transparency of data storage is crucial to stackware
> applications.

The UNIX and Windows restriction of executables being unable to write to
themselves (Rev carries this forward to Mac OS as well for consistency) does
require some re-thinking of data storage if you're used to working in
Mac-specific xTalks.

Fortunately Rev makes it easy:

You could store your data in an external text file, but then you'd have to
parse it to have any useful structure to it.

If the nature of your data suggests a need for more structure than a single
block of text, you could use a separate stack file for data storage.

The main benefit of using a stack file as opposed to a text file is the
hierarchical structure afforded with objects and their custom properties.

Remember that every Rev object can have custom properties, and even multiple
sets of custom properties.  Accessing these is very fast -- much faster than
fields, and only a tiny bit slower than globals.  You can use array notation
if you like, and they can store binary data as well as text.

Since a new stack file contains one card in one mainstack, you instantly get
this rich structure for organizing your data (for just 363 bytes of
overhead):

                           stack
                             |
         ------------------------------------
         |                   |              |
  custom property    cust. prop. set        |
                             |              |
                       custom property      |
                                            |
                                           card
                                            |
                             ---------------------------
                             |                         |
                      custom property         cust. prop. set
                                                       |
                                               custom property


Of course you can enrich this data hierarchy by adding more cards to the
stack, adding objects to the cards, adding substacks, etc.  With multiple
property sets, every object inherently has a two-dimensional data space;
with multiple objects in nested groups across multiple cards in mutiple
substacks, you can effectively create an n-dimensional data space in one
stack file.  Using the substacks, cardNames, customKeys, and
customPropertySets properties you can instantly obtain lists of any
collection of members at any level of the hierarchy.

If you need a rich hierarchy with a lot of objects when the user creates a
new data file, you can have a template data stack in your app's stack file,
use the clone command to make a copy in memory, and set the filename propery
of the newly-cloned data stack to assign it a file path; when you issue a
save command for that stack, it'll save to the assigned path.

Because the storage space and access speed overhead are so low with custom
properties, you can use stack files for data sets as large as memory allows
and expect pretty snappy performance.  In this sense, it rivals Panorama and
other RAM-based databases, with all the ease and flexibility of an xTalk.

A simple example of using custom props for data storage:

  on StoreData
     repeat with i = 1 to the number of flds
       set the UserData[i] of stack "MyDataStack.rev" to fld i
     end repeat
  end StoreData

  on DisplayData
     lock screen
     repeat with i = 1 to the number of flds
       put the UserData[i] of stack "MyDataStack.rev" into fld i
     end repeat
     unlock screen
  end DisplayData


Tip: if your data file needs to store images, just copy them to the card(s)
of your data stack, and use buttons in your app's UI stacks to dispay those
images by setting the button's icon.  Unlike most other xTalks, Rev icons
have no practical limit on size, and using this method allows a single image
object to be displayed in multiple button objects with minimal RAM overhead.


Another tip:  If you want to store data in a way that isn't obvious for
someone to read if they open the stack file in a binary editor, you can use
the compress and decompress functions on data you store in custom props,
which will also reduce the size of the data file.


-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 2.0: Publish any Database on Any Site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc




More information about the Use-livecode mailing list