[Seaside] components via meta-data?
itsme213 at hotmail.com
Sun Jul 2 18:23:46 UTC 2006
> Hi ItsYou,
er, that would be "itsme" :-)
> Another such project available in public is Magritte,
That looks great!
>> - (meta)operations on those objects
> Mewa doesn't support that. For Magritte this is only supported on a
> very basic level, such as for comparison operators, though it is
> definitely feasible on a more generic level.
>> A meta-object (in this discussion) is NOT a class; rather, it is a
>> proxy-like object carrying meta-information for a specific domain object
>> (instance). (The "meta" terminology comes from Mewa).
> I would not call that proxy, a proxy is something that is on the same
> meta level than the proxied object. A proxy represents the proxied
> object. It is rather a type object.
The usual multipicity of typeObject:object is 1:N. Not so for these
meta-objects. I prefer to call them "objectReflections", see below.
>> A meta-attribute is an object carrying meta-information for the value of
>> specific attribute of a specific object.
> In Magritte attributes and objects are unified, since an attribute is
> an object again. I don't see why the separation of those would be a
> benefit, maybe there is a good reason?
But an attribute is NOT an object. The #value of an attribute, for a
specific owner object, IS an object. This is a big difference.
joe home = 111USA
joe metaAttributeFor: #home , or
joe attributeReflectionFor: #home
is an object that encapsulates
owner = joe
attr = #home
value = 111USA
e.g. the object 111USA would know nothing about the label "home", but the
This can also provide a single context for creating objects. The
Meta-properties of an attribute include "own / create: Boolean". This
attribute should be orthogonal to the multiplicity property (a mistake in
Mewa, imo). Every domain object is created in the context of such a
meta-attribute, and is automatically owned by the owner of that attribute.
There is no need for special treatment of the object collections of the
top-level domain object, just give it some "own/create" attributes. This
works cleaner and more uniformly than the current Mewa example.
One can sometimes force this onto the object, but this is often a mistake.
e.g. if I have a class Person, each person can play many different roles
(e.g. referred via attributes of other objects): author, father, project
>> A meta-operation is an object carrying meta-information for a specific
>> operation that might be invoked on a specific object.
> OMG provides such a model called EMOF. Especially your code looks a
> lot like EMOF.
If I have joe with operation >>walk, then I have as many instances of the
meta-operation >>walk on joe, as I have components that might invoke >>walk
EMOF does not have such a concept, afaik. Perhaps it is not sufficiently
informed by Smalltalk-ish concepts like closures :-)
I don't really like the use of the word 'meta' here either, just borrowed
what Mewa used. I prefer something like:
> When I started with Magritte I didn't know about this
> model, however I will try adapt Magritte to bring it closer to EMOF
Good to know, there may be tools you can then leverage.
>> In combination these three carry all the information needed to construct
> I don't think so. My experience shows that this only works for very
> simple user interfaces and very simple domain models without much
> semantics and behvior, such as for an editor/viewer of a relational
Don't you think using operationReflection (expanded, of course) more fully
could improve this? The kinds of patterns that show up in these semantics
and behaviors are amenable to this, imho.
>> joe -- meta-object
>> joe#name -- meta-attribute
>> joe#name= -- meta-operation
>> joe#houses -- meta-attribute
>> home -- meta-object
>> home#address -- meta-attribute
>> "123 hometown" -- metaobject, optimized away
>> home#rooms -- meta-attribute
>> room1 -- meta-object
> Both, Mewa and Magritte can do that. I am missing how the behavior
> fits in there you described at the beginning of your mail.
See joe#name=. I should have shown more operationReflection in the example.
(joe houses at: 1) metaOperationFor: #sell
could be another operationReflection.
These operationReflections correctly encapsulate parameters required,
currently chosen of parameter values, available selections of parameter
values, enabling/disabling of the operation, etc.
>> CLAIM: The component tree should exactly parallel this metaobject and
>> metaattribute structure (by default). So here are the components in that
>> tree, and the (meta)-things they connect to:
> The parallelity does not work in general as I explained above.
Hmm. Why not? There is a DOM-tree in the browser, and a parallel component
tree in the server. All I am suggesting is that every node of the component
tree be one of:
- objectNode -- attached to an objectReflection
- attributeNode -- attached to an attributeReflection
- operationNode -- attached to an operationReflection
>> As always, some of the elements in the above tree might change
>> with Ajax e.g. a viewer might be replaced by an editor when the little
>> "edit" link is clicked; but the editor would still be attached to the
> I have such an extension for Magritte, though it is (currently) only
> used in a commercial project.
Any plans to release it?
Is Magritte very experimental, or tested and robust?
>> I believe all the components in this tree could be generic by default,
>> the meta-objects constructed automatically given a few meta-data hints.
> This doesn't work either. People need custom components for custom
True. Hopefully small, encapsulated deltas that can be composed. Once we
work at the meta-level we need a set of operations to compose these
meta-objects as objects and derive their resulting composite properties,
including propagating defaults, overriding, adding/appending, etc. just like
class inheritance is largely hard-coded today into class structure.
>> Not sure how Seaside deals with Ajax right now, but we might need some
>> machinery between the tree and domain objects so an (Ajax) operation that
>> replaced one component might also update other parts of related
>> in the tree. Ajax-induced updates would propagate up to the tree root
>> collecting component updates, before going back to the client.
More information about the Seaside