[Seaside] components via meta-data?

[itsme213]

Hi Lukas,

> 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.

OK.

>> 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 
>> a
>> 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.

Suppose
  joe home = 111USA
then
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 
metaAttribute would.

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 
manager, ...

>> 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 
on joe.

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:
- objectReflection
- attributeReflection
- operationReflection

> 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
>> components.
>
> 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
> database.

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
>>           room2
>>       vacation_home
>>     joe#friends
>>       bob
>
> 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. 
e.g.

(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 
>> dynamically
>> 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 
>> same
>> meta-instance.
>
> 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, 
>> all
>> the meta-objects constructed automatically given a few meta-data hints.
>
> This doesn't work either. People need custom components for custom 
> projects.

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 
>> event
>> machinery between the tree and domain objects so an (Ajax) operation that
>> replaced one component might also update other parts of related 
>> components
>> in the tree. Ajax-induced updates would propagate up to the tree root
>> collecting component updates, before going back to the client.
>
> http://scriptaculous.seasidehosting.st

Looks nice!

Cheers,

Itsme :_)