An alternative would be to
* use a delegate to render the component by itself.
* use *one* listener method for all actions (called from an
ActionLink-type link), which delegates to a custom listener in a service
object, depending on some parameters -
so you create a clear contruct for rendering and actions.
however using form fields would be problematic, unless you do some java
script to include them as link parameters.
Cheers,
Ron
Eric Williams 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]
