Re: component definitions

I'll keep the "nested component configuration namespaces" 
item on the list of my personal favorites. Maybe, with 
perseverance ... Also, I dont see this particular item as a 
conceptual compromise.

regards,
Christian

---- Original message ----
>Datum: Thu, 19 Dec 2002 08:48:55 -0500
>Von: "Howard M. Lewis Ship" <[email protected]>  
>Betreff: Re: [Tapestry-developer] component definitions  
>An: "Christian Sell" <[email protected]>, <tapestry-
[email protected]>
>
>I would suggest checking out the relevant portions on the 
Wiki.
>
>Easing adoption of Tapestry is a big concern for us.  
Release 2.4 focuses on
>this, making compromises that will ease adoption.
>
>Basically, less is going into the specs and more into the 
HTML, but it's
>still very much Tapestry.  Most simple components (Insert, 
Conditional
>particularily) will NOT have to be in the page specification.
>
>In addition, Tapestry is using a search path mechanism to 
find page and
>component specifications rather than making you declare them.
>
>How Geoff is going to make Spindle support this is anyone's 
guess!
>
>----- Original Message -----
>From: "Christian Sell" <[email protected]>
>To: <[email protected]>
>Sent: Thursday, December 19, 2002 8:34 AM
>Subject: [Tapestry-developer] component definitions
>
>
>> Hello,
>>
>> I would like to bring up again the point about component
>> configurations. As far as I remember there was no final
>> answer.
>>
>> In Tapestry component configurations have to be repeated 
for
>> every page and component which embeds the component.
>> Moreover, all components have to be assigned type aliases 
in
>> the application file (I am not familiar with the workings 
of
>> libraries yet).
>>
>> This is in contrast with other component systems I have 
used,
>> among them tiles (BTW, if looked at solely from the
>> standpoint of presentation components, the tiles model is
>> quite good. What it lacks is behavioral componentization). 
In
>> those systems, component configurations are/can be kept in
>> dedicated registries from where they can be referenced by 
any
>> other component/page in the application. This allows reuse 
of
>> component configurations, and possibley more effcient
>> cacheing than is done today by tapestry. Of course it is
>> conceivable to maintain nested registry namespaces, even 
down
>> to the level of the individual page/component.
>>
>> I also dont quite see the need for the type alias 
definition.
>> Why not reference components by the complete path to their
>> location, as is done for java classes? BTW, I also see
>> WebOGNL doing it this way (e.g. component
>> id="/path/path/name").
>>
>> Does anyone else think it would at least theoretically make
>> sense/be possible to introduce these items into tapestry?
>>
>> thanks,
>> Christian Sell
>>
>>
>> -------------------------------------------------------
>> This SF.NET email is sponsored by: Geek Gift 
Procrastinating?
>> Get the perfect geek gift now!  Before the Holidays pass 
you by.
>> T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
>> _______________________________________________
>> Tapestry-developer mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/tapestry-
developer
>>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: Geek Gift Procrastinating?
>Get the perfect geek gift now!  Before the Holidays pass you 
by.
>T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
>_______________________________________________
>Tapestry-developer mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/tapestry-
developer


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/