>> 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
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
Fortunately MC/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
| | |
custom property cust. prop. set |
custom property |
custom property cust. prop. set
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:
repeat with i = 1 to the number of flds
set the UserData[i] of stack "MyDataStack.rev" to fld i
repeat with i = 1 to the number of flds
put the UserData[i] of stack "MyDataStack.rev" into fld i
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.
Fourth World Media Corporation
Custom Software and Web Development for All Major Platforms
Developer of WebMerge 2.0: Publish any Database on Any Site
Tel: 323-225-3717 AIM: FourthWorldInc
Posted 7/12/2002 to the Use-Revolution List
(See the complete thread)