>Could you describe the application you're building, at what about it makes it >so that you require this complex configuration?
Thanks, I have already explained my scenario several times. See more below. >Where do its parameters come from? Do you mix and match parameters specified in the >page specification with those from this "elsewhere" parameter specification? yes, in the sense that "elsewhere" means enclosing levels. Thats what its all about. Think of it like inheritance in Java - I dont see anything dangerous about that. >Who has priority? the innermost level >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. I dont know why you mention the border. But, as I wrote in an earlier mail, it does in fact illustrate the redundancy problem quite well (I'll repeat): Border needs a parameter which provides the items to be displayed on the menu (or in tabs for the workbench example). This parameter has to be re-specified for every page using that border, even though it never changes. In the example programs, you circumvent this by (1) in the case ot the border tutorial, calling back into the engine to get a statically defined value (2) in the workbench example, defining the menu items in a property file In both cases you are moving configuration information into a separate medium - obviously to avoid the redundancy you would be faced with if you were to use the tapestrys component configuration mechanism. >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. I am not hitting a "roadblock" - I am finding myself re- writing the same stuff over again, and that is something I dont like. And, I must again object against the term "dangerous". Christian ------------------------------------------------------- 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
