A few notes ... Being able to specify the absolute path to a component was phased out in 2.2 because it makes it impossible to determine which namespace a particular component should belong in. Further, in 2.4, component specifications can be located on the classpath or within the context (that is, inside /WEB-INF, and elsewhere).
I'm concerned that this discussion is wondering off tangent based on a phantom problem. Could you describe the application you're building, at what about it makes it so that you require this complex configuration? I have a gut rection against this configuration issue because it introduces a dangerous ambiguity about how any individual component is configured: Where do its parameters come from? Do you mix and match parameters specified in the page specification with those from this "elsewhere" parameter specification? Who has priority? In practical application development with Tapestry, the pattern is: 1) Put all the common stuff in a Border component. Configure the components in the Border component just once. 2) Wrap all your pages in the Border component: <span jwcid="border"> My page content, with component and all. </span> 3) Pass in parameters from the page to the Border for anything that can't be statically defined (i.e., page title). <component id="border" type="Border"> <static-binding name="title">Shopping Cart</static-binding> </component> So, the Border component is your shared component configuration, and there is an elegant and unambigous way to supply anything that the varies from page to page. A large part of Tapestry development is based on people hitting actual roadblocks. I'd like to hear about the roadblocks you've hit, that make you feel a drastic and dangerous solution is necessary when it seems to us, the more experienced Tapestry developers, that Tapestry already provides the solution you are seeking. -- [EMAIL PROTECTED] http://tapestry.sf.net > >I think Mr. Sell is in a kind of "JMX" mindset, where there > is one > >configuration (possibly assembled from multiple places) that > is shared by > >everyting. > > Howard, > I hope its ok if I address you that way. You may call me > Christian, too. > > In fact "assembling" is not the right term. As I said > earlier, I am arguing in favor of "nested configuration > spaces". So a component configuration can exist on any of a > number of nested levels (application, page, component). A > configuration on an inner level may override a configuration > on the outer level. That way the current mode of defining > component configurations only at their immediate point of > usage (page or component) becomes a special case of the > general principle. You can still choose to do it as it was > done until now. > > I must say I have somewhat of an uneasy feeling leading this > discussion. Is this an open community, or is it meant in the > sense of "take it as it is, or go away"? > > > > >Tapestry has no special knowledge about its components. > Whether create an > >Insert or a contrib:Palette (pretty much opposite ends of > the spectrum), > >Tapestry just works from the name to a specification. > > > >You couldn't just configure one "Insert" component (or > one "Foreach") because > >each instance of it, on each page, is unique, driven by the > specific content > >and behavior of that page. > > > >And each individual page in an application is, itself, > unique. Tapestry does > >NOT enforce any "standard layout". The fact that most pages > in an application > >resemble each other is an "engineered coincidence" ... and, > many applications > >will have pages that are exceptions to the rules. > > > >You engineer such a coincidence, in Tapestry, by defining a > component that > >provdies the basic layout of your page. I call that basic > layout > >a "boilerplate". You'll typically map a boilerplate to a > component, which (by > >personal convention), I call "Border". > > > >The Border component will provide the <html> tags (using a > Shell) and the > ><body> tag (using a Body) and, often, provides a title, > stylesheets and a > >nested table or two containing icons, copyright messages, > basic navigation and > >so forth. > > > >If your application has multiple boilerplates ... for > example, public pages > >that don't require a login, and private pages that do, you > either create two > >Border components, or parameterize a single Border component > to serve both > >purposes. > > > >The magic of Tapestry is how easy this is (in 2.3, how easy > relative to other > >frameworks, in 2.4, just plain how easy) ... just drop the > components in and > >they work, regardless of page, boilerplate, application ... > whatever, they just > >work. > > > >All these specifications, parameters, services, request > cycles, and so forth > >exist to support this compartmentalization. > > > > > >-- > >[EMAIL PROTECTED] > > > >http://tapestry.sf.net > >> Christian Sell wrote: > >> > >> >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). > >> > > >> > > >> > > >> I think the slight awkwardness of specifying the small > bits of XML to > >> hook a component into a page is needed to allow multiple > numbers of the > >> same component on a single page. Remember, as part of > specifying the > >> component, you need to specify a unique id - partly this > is a standard > >> XML restriction for the ID attribute type, but also so > that Tapestry can > >> identify uniquely which component is being referred to. > >> > >> Richard. > >> > >> > >> > >> > >> ------------------------------------------------------- > >> 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 ------------------------------------------------------- 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
