[Seaside] components via meta-data?

[Lukas Renggli]

Hi ItsYou,

> QUESTION: Can we build very smart Seaside components automatically from
> meta-data of the domain objects, and still require a very small amount of
> meta-data for customized components?

Yes. Several people have done this for public and commercial projects.
Another such project available in public is Magritte, see:

http://www.lukas-renggli.ch/smalltalk/magritte
http://www.iam.unibe.ch/~scg/Archive/Diploma/Reng06a.pdf

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

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

> 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. When I started with Magritte I didn't know about this
model, however I will try adapt Magritte to bring it closer to EMOF
with the next major version. So far the evolution of Magritte was
solely driven by requirements we had when developing new Web
applications.

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

> Assume there is a component tree consisting of nested viewers and editors.

Magritte builds such trees, but allows you to customize any aspect of
the generation, this is to manually display or change the default
behavior using Smalltalk code. I think the possibility to do this is
key to a meta-level framework that should be usable in different
contexts.

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

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

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

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

> 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

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch