Custom Properties vs globals

[David Bovill]

On 17/07/07, Kay C Lan <lan.kc.macmail at gmail.com> wrote:

> I just wish to confirm that although you can:
>
> put line 3 of the cMyCustomProp of stack "myStack" into myVar
>
> you can't:
>
> set line 3 of the cMyCustomProp of stack "myStack" to myLine


Yes - the latter may read well and is a nice feature request- but Rev
presumes the bit after "line 3 of" is a regular container / field / variable

My rule of thumb is to almost never use globals :) To be precise only use
globals when you really really want and will want at all times in the future
for the data to be globally available to all stacks in the environment.

   - In every case where I may in the future want more than one of the
   "thing" I use custom properties.

To make the syntax easier I create a small suite of handlers so that i can
use something like:

set the model_IndexLine ["3,cMyCustomProp"] of stack "myStack" to myLine


which I often abbreviate to:

set the model_IndexLine [3] of stack "myStack" to myLine


So the model is associated with a suitable revolution control (I call it a
modelObject), and if you need another copy (ie another calendar as in the
previous example posted) - you use another place to store your new version
of the model.


More complex Bit

The main reason is for this is actually data abstraction. The problem with
custom properties is that the data is in your stack - which means that your
(interface) code and your data are in the same place - so you might want to
look at using text files - then you might later want to look at XML for
interoperability - or an SQl database... that is the issue is as the app
evolves you may want to change the way you store your data.

The solution to that problem is data abstraction  - ie put a little code in
between the GUI and the data so that you can make a switch there and
everything keeps working. In my case I know that I am going to switch a lot
of stuff over to database - sqlLite mostly (sorry Ruslan :) so I have been
using this approach in general knowing that I can much more easily switch
from arrays to other ways of storing data. I can get on with the application
logic using arrays for now and deal with the data model later.

I'm still in the process of working out and refining (well lets call that
hacking) the syntax, and I understand a few things in this area are likely
to change / improve a lot in the future  - so your questions are good and I
for one have got a lot to learn in this area.

NB - actually in the examples given I tend to use commands and functions -
as i have found the "models" tend to get more complicated over time and as
unfortunatley you cannot pass arrays to setprop handlers.... so setprop and
getprop are usually out for me for data access - only GUI stuff or very
simple data. Instead i use "model_GetBlah" and "model_GetBlah" all in the
same section of a script.