[Seaside] Metamodel and Form support

[Derek Brans]

Adrian,
What is the status of the metamodel code?

On Saturday, December 14, 2002, at 03:54 PM, Adrian Lienhard wrote:

>
> ----- 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
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>
>
Nerd on a Wire: Web and Information Solutions
Website Design - Database Systems - Site Hosting
604.874.6463
mailto:info@nerdonawire.com
For more information, visit http://nerdonawire.com