Rick,
Did you consider making your Action a TilesAction so you can put the "title"
into the context however you want? That way, if you do a CRUD methodology,
you could do a context.putAttribute("title",new String("Edit")); or "Add"
depending on your Action's CRUD method.
Heck, you could also do that to the "body" attribute and change a JSP
inserted into the middle of your template. You could have a definition look
like this:
<definition name=".generic" path="/WEB-INF/pages/common.jsp">
<put name="title" value="Default Value" />
<put name="body" value="/WEB-INF/pages/default-center.jsp" />
</definition>
Then, in the extreme, all of your actions could se the title and their own
body choice. Viola! One template fits all!
Regards,
David
-----Original Message-----
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Monday, January 24, 2005 5:18 PM
To: Struts Users Mailing List
Subject: Best practice for dynamic Title values using Tiles?
I'm switching back to using Tiles instead of Sitemesh and I remember one
issue that I found annoying with Tiles and I'd be curious how you guys
handle it. Say I have a form that is going to be reused for both "Edit"
and "Add." I want the <title> attribute to read something like "Add
Employee" or "Edit Employee," depending on what I'm doing. It seems
silly to have to create multiple definitions in my tiles-definitions
that are essentially the same exact definition except that the title has
changed (potentially you might want a definition to be used for more
than just the two that I mentioned). This also requires that my struts
config has to be set up to forward to multiple tiles definitions when
its really the same page layout but with a different title and could
really just require one definition to use.
I've thought of different ways I might want to handle this (ie set a
title in request scope before leaving action and have the header.jsp
look for this, or maybe use a filter or over-ride RequestProcessor?) I'm
curious if others have run into this. Maybe the latest Struts/Tiles has
a solution that I have not looked into.
Thanks
--
Rick
---------------------------------------------------------------------
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]
