Actually, what we found was that some components had registered to be notified and weren't getting the "beginPageRender();" call. So, we do a check and pass it in.
BTW, we are 3.03. What we wanted originally was some way to generate a page with dynamic components without having to define every single one inside of a single page. We have 120 components. Imagine if you will, a single page with 120 different components embedded in it. Instead we have one .page with 120 of these: <component id="passwordGeneration" type="PasswordGeneration"/> <component id="dataMapVo" type="DataMapVo"/> <component id="headCrumbs" type="HeadCrumbs"/> <component id="taskletView" type="TaskletView"/> <component id="portalMenu" type="PortalMenu"/> <component id="menu" type="Menu"/> and one .html with 120 of these: <span jwcid="passwordGeneration"/> <span jwcid="dataMapVo"/> <span jwcid="headCrumbs"/> <span jwcid="taskletView"/> <span jwcid="portalMenu"/> <span jwcid="menu"/> Each of these is a Tapestry Component, they all have a .html, .jwc and a .java class. We have a three man team that maintains these components. If anything the Border sounds better to me, but it is an issue to link the pages. Mark -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thu 3/30/2006 12:35 PM To: 'Tapestry users' Subject: RE: On-the-fly UI construction That he does, but it still seems hacky to me. Are you doing the PageRenderListener stuff so that your components can be "set up" by the enclosing page? What I did for that sort of situation is put a "decorator pipeline" on my "BlockFactory" service. You then register block decorators which will have a chance to do "stuff" to the block before it's handed back to the caller (like set up page properties and the like). The BlockFactory sends the block (looked up via its component address) through the pipeline before returning it. -----Original Message----- From: Mark Stang [mailto:[EMAIL PROTECTED] Sent: Thursday, March 30, 2006 2:24 PM To: Tapestry users; Tapestry users Subject: RE: On-the-fly UI construction Yeah, looked at it and also at something someone else had created called "Dynamic Block" or something like that. Then we had some guy name "Howard" come in. He spent a couple of days here teaching us Tapestry. And when he was done we asked his advice and this is the code he wrote. I could be wrong, but he seemed to have an idea about how this whole Tapestry thing works. -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Thu 3/30/2006 11:33 AM To: 'Tapestry users' Subject: RE: On-the-fly UI construction 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
