>I never thought of
> using the setprop/getprop just like a "handler" - I've always assumed that
> it was 'attached' to the object that is getting its property set/retrieved.
You should try, Trevor. I got very found of this approach myself after hearing David hint
me on the way getprop and setprop could be used this way and reading on design
patterns & OOP approaches & MVC. It encourages to write your code in terms of widgets...
and the advantage of widgets is that you create components that you write once but use
anywhere, by simple drag and drop in another stack.
I am always a bit sad when I see on the lists proposals of this kind received with comments
like "no use for reusable components or a OOP approach, I can write any code from
scratch in less than 10 minutes". The reasons to become interested in re-usable
components is not the economy of time or of lines of codes. It is the potential for a
gradual increase in the quality of the functions and widgets available within the
community, which has the potential to immensely benefit us all, skilled and unskilled
users alike. I am sure that any of you can easily write a powerful application from scratch
in only a few hours. A components-based approach provides you with a framework where
you have some *other* choice than do it that way. Hence, a problem in the runrev
community is that less skilled users are forced to follow the same approach as yours but
without the benefits of your experience and level of skill. Though some stacks are
available in open format here and there, some relatively advanced level of skill is still
required to understand the code well enough to adapt it. With a components-model, you
let others re-use components without having to understand the code. You can if you want
(and I know Mark wants this ;-) ), but you don't *need* to. Total "control" comes with
benefits, but also with costs. A component-based approach give you the ability to weight
benefits and costs differently in different contexts of use.
Sure, in the short term, this may means that open alternative of some of the plugins you
sell may appear. However, in the longer term, this means that the size of the community
will be expanding, as newcommers will find it easier to start using revolution. Professional
developers will also benefit from the fact that it becomes increasingly easier and faster to
assemble new applications, using widely tested components. Though there may be fear
that the availability of quality components may negatively impact on your reputation, the
fact is that the whole is always more than the sum of the parts. To get the whole right
requires a talent and expertise that cannot be acquired in only a few months.
Like you, David, I take a MVC approach for the coding of widgets.
The view is kept separate from the model. This means that I can choose to display any file
name the apple way, with ellipses when the file name is too long for a text field "/folder/
fol.../file.txt". Alternatively, I can decide to display it the BBedit way, file.txt -- /folder/
folder/ with a single change in property or parameter value The way I choose to display
the file won't affect the inner working of the library.
Because the view is also separated from the controller, I can very easily change my mind
on whether the file value should be presented in textfield 1 rather than textfield 2, in a
button, or should not appear at all.
I suspect that I have something very similar to what you have done, David. How similar, I
don't know. Last time we discussed of this, you said you wanted to keep your widgets for
your private use and I wanted to construct a catalogue of widgets, mixing open and paying
ones, made available to the community. Given our divergence of view, I have avoided
looking at your code so far. I was afraid to inadvertendly re-use some of your solution. I
have also done my best to go in directions that don't repeat the work you have already
done (providing a model for embedding widgets within widges).
For instance, you will note that an important difference with anything mentioned in this
group is that I have chosen to explore the use the textfields to store library scripts.
Because I use textfields to store library functions, I can rapidly provide a class and
subclass model, with a card in my library stack containing mutltiple textfieds (card = class,
textfield = subclass). I find using a textfield very efficient as it lets me organise my
functions into very small chunks that can very flexibly be added to any stack.
Because of this, I can more easily achieve encapsulation. Hence having a script stored in a
object means I can store custom properties at the level of this textfield object rather than
at the level of the card or stack, as is the usual approach. The custom property value can
only be changed when referencing to the correct object.
Because I use textfields, that is fairly small chunks of functions, I am encouraged to write
my functions in such a way that the dependencies with functions in other textfields are
absent or at worst limited and unambiguously declared.
Because I use textfields, I can more easily run unit testing and make sure that all functions
run properly without any call made to any function not declared as required.
Because I store scripts in textfields objects rather than card or stack level, I can get over
the complex prefixing conventions defined in this group. As I can easily get encapsulation
when using custom properties of a group holding a widget, I can replace a syntax like that:
> stsXML_GetRSSChannelProperty(<prop> [,<channel> [,<doc>]])
> stsXML_SetRSSChannelProperty(<prop>,<newValue> [,<channel> [,<doc>]])
With a syntax like this:
get the RSSChannelProperty[params] of libpath["lib_xml"]
Without creating any conflict. More info at:
Obviously, an important problem with this approach is the fact that I still want to have
some shared libraries to be in the back of the message path and I am limited to 10 objects
in the front and back script, in a standalone or played stack. The only get around I have
found so far is to add a "building" stage, which will run some operations that have for
effect to merge all library scripts together within a card script. I expect this suggestion to
be immensely impopular here. Ah, yeah, and other criticisms made by Trevor apply. Only
one parameter for a getProp... But it is quite easy to send a string that contains all
parameters or to set a custom prop to this sequence of paramaters. Anyway a cleaner
approach is probably to set the properties of the function rather than call a function that
requires very many parameters. No pass by reference. But if you use encapsulation, you
don't need to pass by reference anymore. What you can then point to a custom property
and update it from many places.
It would be nice if we could find a way to make our work (David Bovil, David Burgun, Mark
Wieder, etc.) compatible.
If a workshop on this is planned at Monterey, then unfortunately it is about impossible for
me to finance travel + conference costs to get there.