[Seaside] Metamodel and Form support

[Adrian Lienhard]

----- Original Message -----
From: "Avi Bryant" <avi@beta4.com>
Sent: Saturday, December 14, 2002 10:06 PM
>
[...]
> 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.

Yes, first I started with "AttributeSet" but then I thought that it could be
missleading because it is not a kind of Set... but this might be less
confusing. Anyway, renaming is no problem.

> 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

Agreed. Maybe I wanted to be too general...

[...]
> 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 :).

Thanks for the feedback and ideas. Actually, I would apreciate that what I'm
doing can be used by others. I don't mind if you come up with an altered
version and say, "look, I've changed this and this". I am quite open ;-).

Adrian