[Seaside] Metamodel and Form support

Sat, 28 Dec 2002 18:56:54 -0500

heh.  sorry for the spurious post.  my wireless mouse got confused when 
I switched batteries and it seems to have decided to respond to this 
thread.

nice pattern, btw.

cheers, rob

On Saturday, December 28, 2002, at 06:26 PM, Robert Withers wrote:

>
> 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
>>
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>