[Seaside] Metamodel and Form support

[Avi Bryant]

On Sat, 14 Dec 2002, Adrian Lienhard wrote:

> There are two parts: The metamodel (a model which describes your actual
> domain model) and the form support which now depends on the metamodel. The
> leading idea is that a metamodel which has to be defined only once, delivers
> the neccesary information to the components.

Adrian,

I agree with Frank that the name "Page" is a confusing one - in a web
application context, page has a very strong meaning already and it's best
not to overload it.  But pages are also the part of your model I have
trouble understanding - I think I see what you're trying to do (make the
metamodel extensible to cover new types of information), but I'm not sure
I like the way it's done.  Instead having a #Naming page and a #Type page
for each attribute, I'd rather have a single Attribute class that had
'name type' as inst vars, containing AttributeName and AttributeType
objects, for example.  Adding new types of information should be rare
enough that inst variables could simply be added to Attribute as needed.
This would do away with the nested Dictionaries in Metamodel, and would
allow the Attribute class to provide more convenient ways of building up
the structures - I could see having one method on Attribute for each of
what you now have as "page" types, ie, #addLabel:description:,
#addType:isMultiple:, or some such, that would create the appropiate
objects.  I also think that Attribute should probably know the selector it
is describing (and these should be describing selectors, *not* inst vars),
so Metamodel just becomes a simple Set of Attributes.

The way you have Fields working is interesting - not depending on the
metamodel, but just loading it in as defaults.  Again, I can see the logic
here, but actually I think it's more useful to just say "Attribute is how
you control this form, and if you want to customize it, give it a
different set of Attributes".  That is, right now you basically have two
metamodels - the attribute and the one the form actually uses - and you
translate between them.  I think it's more valuable to consistently use
one - for example, Field>>value now looks something like

model perform: selector

whereas if you have a decent Attribute class, it should look like

attribute valueForObject: model

which is ultimately a lot more flexible.  If you keep two separate
metamodels you'll either have to make them *both* that flexible (which
isn't realistically gonna happen) or sacrifice the flexibility on one of
them (in which case, why bother having the nice one?).

These are just suggestions, of course - you do what works best for you,
and if I don't like it, I'll just write an alternate implementation :).

Avi