Hi, We generated a "view" component that dynamically draws the "current" component. So, for instance if a component is read-only we swap out the editable component with the read-only component. We only have one page, but we have MANY components (~120). The page is the "frame" around everything, the "view" draws the "current" component. We define all of our components in one "Holder" page (non-viewable) and then just swap them from the pool as needed.
regards, Mark -----Original Message----- From: Michael Henderson [mailto:[EMAIL PROTECTED] Sent: Wed 11/23/2005 10:20 AM To: Tapestry users Subject: Re: Dynamic sub-components Hi, Blocks do not have to be declared in the same page as the @RenderBlock used to render them. They can be in another page entirely. I'm doing this right now to swap in parts of pages based on user-role. The block parameter of my RenderBlock is bound to a method which uses the role name of the logged-in user to construct a page name, then invokes getPage() on the request cycle with the page name. I have a page for each role with a single block in each page, all blocks have the same id. Once I have the page it's a matter of using getComponent() on the page to get the block. Of course, I don't have to pass any parameters into my blocks... Mike On Wednesday, November 23, 2005, at 09:12AM, Eric Williams <[EMAIL PROTECTED]> wrote: >We are migrating a Struts application to Tapestry 4 beta 13. >Unfortunately, the test case we're trying to deploy seems to push >Tapestry's boundaries, and we're trying to figure out the best way to >solve our problem. Any help would be much appreciated. > >We have a calendar application that draws out a user's schedule. Each >day they might be doing something different. Depending on their activity >for that day, we want to provide different functionality. Monday might >have a business meeting, so meeting details will be shown along with >controls to adjust meeting properties. Tuesday might be a sales call, >which will render differently and have different functionality. And so >on. > >We believe each activity type should be rendered by a different >component. We want any developer in our company to be able to create a >new activity type and corresponding component and have it just work. In >our Struts application, our database stored a class name for each >activity type, and we simply loaded the class dynamically and asked it >to draw itself. > >We see a couple potential options in Tapestry: > >Option 1: Within the calendar component, create Block components for >each of the activity types, containing their related components. In the >database, store the block name. Use a RenderBlock to draw the proper >block for the activity. > >This seems to be the "Tapestry way". The disadvantage is that when a new >activity type is created, the calendar component's template needs to be >modified to include a new Block and the application needs to be >restarted. > >Option 2: Use Tapestry's markup writer and related facilities to >dynamically draw content. Use the database to specify the name of the >class that can do the rendering. This will alleviate the problem of >having to modify the calendar component each time a new activity is >created, and we theoretically should be able to deploy new activity >types without restarting the application, but it also means taking on >the complexity of the markup writer and losing the simplicity of HTML >templates. > >Option 3: Use Tapestry services to dynamically load components when >needed, and render them. I'm not sure if this is even feasible, or >whether we could cache the components. > >Option 4: Something else we haven't thought of? > >In short, we want to dynamically bring new components into the mix, and >reference them dynamically. We could live with having to restart the >application each time a new component is added, but we'd really like to >avoid having to fiddle in the outer calendar component. Any help or >ideas would be greatly appreciated. > >Regards, > Eric > > >--------------------------------------------------------------------- >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]
