best data format

Trevor DeVore lists at
Mon Mar 28 23:29:09 EDT 2011

On Mon, Mar 28, 2011 at 10:39 PM, Todd Geist <todd at>wrote:

> Where is a good place to stick all this data?  custom Props on substack?
> I am going to try to mimc some of the things I like about the web
> frameworks
> I have used lately.  I am not sure if this will be possible but I am hoping
> to create some kind of local representation of the sever data. Something
> like the Model in MVC. Not really in the sense of OOP, but more just as a
> place to encapsulate logic that operates on the data.
> For example if I building a contact management app, is there some place I
> can build some logic that describes a person and what it person can do?
> I think I see I can create custom props on an object like a button. And
> even
> setup some getters and setters thats a start.
> Has any one gone down this path?  Does it get you anywhere?

My take on it -

When trying to create custom objects that play the part of a model I usually
turn to library stacks (this will actually be part of one of my
presentations at RevLive). I then write handlers for getting and setting
object data, performing actions on the object data, etc. Storage of the data
doesn't really matter. It can be in a custom property, an encoded array
stored in a file on disk, etc.

The primary reason I stay away from using getProp/setProp is that the
messages will never be triggered if messages are locked. Since the model
doesn't know what the view/controller are doing there is no guarantee that
messages will be unlocked and you may end up with getProp/setProp handlers
that are never executed. I found myself scratching my head as to why certain
code wasn't executing on more than one occasion. I use getProp/setProp to
extend properties of controls in the view all of the time, however.

Another reason is that I find that targeting a button on a stack somewhere
that is serving as a data object can get a little long in the tooth.

Trevor DeVore
Blue Mango Learning Systems
LiveCode Resources for Developers:

More information about the Use-livecode mailing list