[Seaside] Metamodel and Form support

[Robert Withers]

On Saturday, December 28, 2002, at 05:49 PM, Adrian Lienhard wrote:

> Hi Derek
>
> At the moment there are several attribute classes (such as type, 
> naming,
> validationrules) which I use for my form support. I started using it 
> for my
> current project and it seams useful till now. What's still open, is 
> how to
> make the form enough flexible for nice custom design (but this is 
> something
> else...). And of corse, the metamodel could be improved (feedbacks very
> wellcome!).
>
> What would be interesting is to see how the metamodel can be used for 
> other
> components. E.g. the exsiting report-component. Or maybe it could be 
> the
> place to define security: Defining wich actions exsist and how the 
> access is
> restricted (wasn't it you, Derek, working on something like this?).
>
> You can finde the current source here:
>     http://www.adrian-lienhard.ch/files/squeak/Seaside-Metamodel.st
>     http://www.adrian-lienhard.ch/files/squeak/Seaside-Form.st
>     http://www.adrian-lienhard.ch/files/squeak/tableRowWithFix.cs
> (#tableRowWith:with: had a tiny bug)
>
> Please let me know if I should give some explanation how it works.
>
> Btw, what is the status of your Web Calendar?
>
> Adrian
>
> _____________________
> Adrian Lienhard
> www.adrian-lienhard.ch
> www.netstyle.ch
>
> ----- Original Message -----
> From: "Derek Brans" <brans@nerdonawire.com>
> To: <seaside@lists.squeakfoundation.org>
> Sent: Tuesday, December 24, 2002 3:01 PM
> Subject: Re: [Seaside] Metamodel and Form support
>
>
>> 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
>>
>> _______________________________________________
>> Seaside mailing list
>> Seaside@lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/seaside
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>