Mark,
This sounds like it might be the solution for us. Can you give some more
details on how you accomplished this? In particular, how does your View
component pull the current component out of the pool and draw it?
Thanks,
Eric
-----Original Message-----
From: Mark Stang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005 9:32 AM
To: Tapestry users; Tapestry users
Subject: RE: Dynamic sub-components
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
