On Wed, 22 Sep 1999, Ruediger zu Dohna wrote:
> Greetings!
>
> MetaCard has an elegant and powerful object model, but only for
> prefactured control classes (fields, buttons, etc.). There have been
> several suggestions on this list on how to expand this scheme so you
> can better manage your own i.e. field styles: You can create controls
> of a custom class (that itself is stored in a stack) just as you
> would create any normal control and they would inherit properties
> like colors, border, etc. from that class. This goes beyond what
> template objects do, bacause setting any property of the class would
> change the appearance of all the objects of that class.
Makes sense.
> The next suggestion was to add scripts to these classes, so they
> could show a common behaviour when a custom property (i.e.
> colorScheme) is set or read as well as when a message is sent.
> Messages should be sent to the object first and then passed to the
> class before it is sent to the card etc.
This would just probably work (using MetaCard's existing support for
getProp and setProp handlers).
> A group class (aka background class) would even have several objects
> tied together to act as one custom control type.
Now you've lost me. This seems to confuse attribute inheritance with
some other kind of inheritance. Being able to inherit things like
colors or fonts or even handlers (via the message path) would be
straightforward enough, but inheriting composite objects would be
quite a different thing. If you added a control to the "class" group,
would it appear in every group that "inherited" from that group?
It sounds to me more like what you want is a way to place a group in
stacks other than the stack's it's in. Maybe combined with the
ability to have a separate location each place it appears (kind of
like having a "sharedPosition" property you could set to false).
> Coming to the
> question of where to store these classes, it may be an option to only
> allow backgrounds to act as custom controls, because there is a way
> to store and still edit them.
This question applies to the other kinds of controls as well: should
the "classes" be just a particular instance of an object, or a truly
abstract collection of property/value pairs? The former is how
ToolBook does it and is more xTalk like, while the latter is more like
real OO languages but would probably be harder to learn. There are
also a lot of issues related to where and how that data is stored
(attached to a stack? In a new kind of object? In a text file that's
#included?)
> What I would like to see much more than all of this, are non-control
> objects and classes. I think it would be nice to say:
>
> get the emailAddress of user "Scott"
>
> These objects could either live temporarily in memory or be stored as
> custom properties et.al.! What does everybody else think?
There are a huge number of issue associated with this kind of true OO
system. Persistence (where are these objects stored?) is just one of
them. More serious are things like object creation/deletion and
garbage collection. I think we can learn from the mistakes of the
designers of JavaScript here, who went half-way down this road and
stopped, the result being a very confusing morass of metaphors that
most people have a serious problem getting their heads around. If
it's stored as a custom property, what's so bad about the way you'd do
this now:
get emailaddress[Ruediger] of me
or maybe
get userdata[emailaddress, Ruediger] of me
Regards,
Scott
> Regards
> R�diger
> --------------------------------------------------------------------
> | Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
> | PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
