This topic has been discussed many times here, although I think you are taking it to a deeper level--especially if you implement your own Page Loader.
Here is a posting by Robert Zeigler from Decemeber that says it all (I hope it's considered polite to quote at length). It's seems Tap3-centric, but probably applies to Tap4 as well. Note the quote "static structure, dynamic behavior", which is why this seems so hard/unnatural--you're looking for dynamic structure. Static structure, dynamic behavior is Tapestry's motto--quite different from some other frameworks, which have dynamic structure at their core. Cheers, - Mike http://www.mail-archive.com/[email protected]/msg11463.html Re: dynamically specifying component type Robert Zeigler Thu, 29 Dec 2005 12:20:57 -0800 What you are trying to do is a no-go in tapestry (dynamic specification of the component): tapestry is static structure, dynamic behavior. BUT, you can still achieve the desired affect, and the trick is, in fact, to use block/renderblock. You always render a block component with a render block component. However, 1) the block to be rendered can be obtained from virtually anywhere, and 2) the block to be rendered can /contain/ virtually anything. So, wrap your component(s) to be rendered inside of named blocks. Then use renderblock to pick the appropriate block to render. Something like: blah.html: <div jwcid="@RenderBlock" block="ognl:block"/> blah.java public Block getBlock() { IPage page = getRequestCycle().getPage(lookupAppropriatePageName()); return page.getComponent(lookupAppropriateBlockName()); } someotherpage.html <block jwcid="[EMAIL PROTECTED]"> <!-- put here your html, or your custom components, or whatever the heck you want... this is where the "dynamic" portion would go... whatever you were trying to specify as a component type string before. --> </block> So, you have only one "application page", which is fine. Now any other "pages" you create simply use BasePage as their class, and they serve only as component holders. Voila. Static structures, but dynamic content, and no if's required. Robert Paul Russell <[EMAIL PROTECTED]> 03/29/2006 03:35 PM Please respond to "Tapestry users" <[email protected]> To Tapestry users <[email protected]> cc Subject On-the-fly UI construction Hi Guys, I've been a silent user of Tapestry off and on since version 4.0 was late-alpha/early-beta. That doesn't sound long, but it's been long enough for me to learn a fair bit about the framework, and to be very impressed with it. The reason I got /into/ tapestry in the first place was actually more to do with Hivemind than Tapestry. I've been pushing a plug-in based approach for about 4 years; Howard thankfully saved me the effort of having to write a framework to actually /do/ it. Now I'm in a position where I'm trying to do both. I'm in the middle of building a proof of concept for a green-field Tapestry app that needs to demonstrate the ability to make /extremely/ modular applications where - amongst other things - individual areas (components) on screens can be contributed by modules, dynamically, on the fly, depending on context. Yes, I'm clearly mad, but there are reasons I'm taking this to the extreme I am. Effectively, what I'm proposing is something very eclipse like: 'Perspectives' will be created, and views will be contributed to these perspectives from other modules. Furthermore, decorations and panels will then be contributed to these views to extend their behavior. All very Hivemind. The complexity here is that effectively I want the ability to embed whole components, designed using standard tapestry semantics into each other. The reason for this is that within this particular application, embedding components in this manner is going to be the norm, not the exception, so building a whole new component framework around IRender is not the route I want to take if I can avoid it! I've been trying to work out how to achieve this goal for a few days now, and I'm not seeing an easy way to achieve it, so wanted to ask the experts. What I've considered so far is: * Creating a component that (indirectly, via contributions and services that actually work out which component to create) calls the PageLoader.createImplicitComponent method. Unfortunately, this method adds the component to the 'containing' component permanently, the component can't change 'per request', which it will potentially have to. * Creating a entirely separate 'component loader' service that replicates the functionality that the pageloader has, but doesn't actually add the component to its container. The issue here is that it (a) it feels too complicated to be the 'right' way, and (b) I'm not clear if this totally breaks the tapestry architecture -- can a component /exist/ without a parent component? * Creating something that looks and works a lot like a component, but has a less static lifecycle. My concern here is that again, that sounds like a pretty major departure from where Tapestry is now, so I'm concerned that taking this tack might just make the solution un- maintainable. I guess the fundamental issue here is that it appears that Tapestry is designed to load the entire page statically once, and then re-use it. There doesn't appear to be a provision for elements of that UI to be constructed 'on the fly', which seems a shame. There are already elements of the standard framework that 'feel' like they could benefit from this ability (the 'describe' framework, for a start), and I can see the potential increasing as more people get into Hivemind. Has anyone else thought about this? Has anyone got any suggestions for ways to think about this that I'm missing? Cheers, Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
