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/ _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
