That seems somewhat (or maybe even very) "hacky" to me. Did you ever try using the Block/RenderBlock strategy, which was designed to handle situations like this one?
-----Original Message----- From: Mark Stang [mailto:[EMAIL PROTECTED] Sent: Thursday, March 30, 2006 1:24 PM To: Tapestry users; Tapestry users Subject: RE: On-the-fly UI construction Where we have a Finite State Machine ("the Tasklet") which has states. The State Name is what we use to look up the component. So, as we progress through the state machine the states change and so does the component rendered. It is possible to configure each state to pull it's components from a particular page, but in practice we have only one page. It is called "Holder" and we generate it via ant from the .application file. We store the FSM in the visit. public abstract class TaskletView extends AbstractComponent { protected void renderComponent(IMarkupWriter writer, IRequestCycle cycle) { Tasklet tasklet = ((Visit)getPage().getVisit()).getCurrentTasklet(); TaskletState ts = (TaskletState)tasklet.getCurrentState(); String pageForCard = ts.getPageName(); IPage cardPage = cycle.getPage(pageForCard); String cardName = tasklet.getCurrentState().getStateName(); BaseComponent component = (BaseComponent)cardPage.getComponent(cardName); if (component instanceof PageRenderListener) { IPage page = component.getPage(); page.beginPageRender(); } component.render(writer, cycle); } } regards, Mark -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thu 3/30/2006 11:11 AM To: 'Tapestry users' Subject: RE: On-the-fly UI construction We do something similar in Trails already. It seems like somewhat of a common paradigm (including components declared elsewhere into the currently rendering page). All of our components (editors for properties) are actually Blocks and we include them via @RenderBlock using a ComponentAddress to look them up by name (page name and idPath actually). Is this what you're doing? -----Original Message----- From: Mark Stang [mailto:[EMAIL PROTECTED] Sent: Thursday, March 30, 2006 1:04 PM To: Tapestry users; Tapestry users Subject: RE: On-the-fly UI construction Our entire application is based on "extracting" components from other "pages". Actually, we have one page where all components are declared (~130). And then for all practical purposes We have only one page to display those components. We have one component in that page that renders the other components. At any point in time we are displaying "one" component. However, that component can be constructed of many other components. It is akin to linking pages together except the components don't know about each other. The main component determines what to display and then renders it. So, at any point in time any component we want to draw is available. regards, Mark -----Original Message----- From: Paul Russell [mailto:[EMAIL PROTECTED] Sent: Thu 3/30/2006 12:32 AM To: Tapestry users Subject: Re: On-the-fly UI construction On 30 Mar 2006, at 01:35, [EMAIL PROTECTED] wrote: > 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. Ah ha! (and thanks for bending the rules and 'quoting at length' ;) > 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. Yes, I had been getting that message from looking at the framework code itself Mike (static structure, dynamic behavior). If I'm honest, I can see that design principle weakening over time with frameworks like Hivemind on the scene that positively encourage 'emergent' behavior. That said, and from my point of view this is the most important thing -- I think that post helps me a lot -- it hadn't occurred to me that it might be possible to 'extract' the component from another page. I've already implemented infrastructure that automatically adds libraries to the application specification based on hivemind contributions, so it's a logical extension of this for the modules to provide their 'plug-in' UI components embedded within blocks in the page, and then render them into the page at runtime. I'll give this a whirl, but I'd be interested to know if anyone else has any appetite for dynamic component creation, or whether that's just me! Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
