Re: component definitions
Christian Sell <[email protected]>
| Newsgroups | gmane.comp.java.tapestry.devel |
|---|---|
| Message-ID | <[email protected]> |
>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/