Hey Charles,
I haven't used Templates much, so i can't give a completely unbiased
opinion, but I'd *highly* recommend looking in to Tiles. Allow yourself at
least a few days to explore all its features (Cedric's tutorial is very
helpful). I'd recommended starting small, and slowly building up to a more
complex framework.
The ability to write your own definition factory is *really* powerful.
Cedric provides a couple examples (i18n and such) that help get you started.
I ended up writing a factory to branch on user role (but you could certainly
write one to branch on say, user agent--present one view to users using a
browser on a PC, and another view (e.g. WML) to users browsing from their
phone). Combined with the factory, i have several tiles config files such
as tiles-config.xml (the default), tiles-config_admin.xml,
tiles-config_user.xml, etc. The factory uses the user's role to determine
from which config file the template definition should come. So, in my
struts-config.xml, the actions simply forward to some template definition
name (e.g. "template.home") but the view for "template.home" can be two
completely different views for users and admins--it all depends how i've
defined them in the config files. Common elements (headers, login page,
etc) can simply be defined in the default tiles-config.xml. Pretty much
works the same as resource bundles and i18n.
One tip to maybe ease the learning process: i recommend settling on some
naming convention early. E.g. i use "template.*" for all tiles template
definitions, "forward.*" for all global forwards, "key.*" for resource
bundle keys, etc. That should help keep things straight when creating your
XML template definitions. E.g.:
<definition name="template.home" extends="template.main">
<put name="window.title.key" value="key.HomeWindowTitle"/>
<put name="page.body" value="template.home.body"/>
</definition>
<definition name="template.home.body" extends="template.main.body">
<put name="title.key" value="key.admin.HomePageTitle"/>
<put name="title.forward" value="forward.home"/>
<put name="subtitle.key" value="key.AdminOverview"/>
<put name="content"
value="/jsp/html/administrator/home/index.jsp"/>
<put name="menu"
value="/jsp/html/administrator/main/body/menu.jsp"/>
<put name="menu.selected_item_index" value="0"/>
</definition>
I think it's kinda neat that, in the end, i don't really have any single JSP
that i can point to and say "that's the home page" or "this is the login
page". Instead, it's just a little blob of XML that just assembles the
little pieces (header, footer, menu, title, main content, etc) to make a
page. It maximizes reuse and minimizes redundancy. Once you've got a basic
framework, it REALLY speeds and eases development because team members
pretty much need only focus on the main content area of their page and
simply reuse all the other pieces.
I also like that the ONLY place in the entire app that i ever refer to JSP
files is in the Tiles config files. The struts-config.xml only points to
template definition names, and the JSPs only ever refer to struts global
forwards. Several layers of indirection make for a lot of flexibility.
This was a huge help when we had to move all our JSPs out from under WEB-INF
(when we moved from Tomcat to Weblogic)...we only needed to do search n'
replace in 3 files--only took a few minutes.
You'll probably also want to put some (or a lot) of thought into how you
organize your tiles. You can kinda see from the path above that i keep
everything under "/jsp" and then i have an "html" layer (that allows me to
have a "wml" or "xml" view at some point in the future). Under that, i
break things into role: administrator, user, common, etc. And then,
finally, the various parts of the site (or part of the page if it's a
framework tile).
Sorry this was a little longwinded :) I guess all i'm trying to say is:
yep, go for Tiles, but give it plenty of time to sink in. Once you're
comfortable with it, you'll probably sing the 'Cedric is my hero' song like
we did ;-)
chris
------
P.S. I didn't even mention how powerful definition inheritance is! *Very*
cool. Real world example: our client decided that the "normal user" view of
the site shouldn't have help buttons on every page any more. No problem!
All i did was insert a single tag into my main template definition for the
user views (since all user pages inherit from that one main view)--that tag
was something like <put name="display_help_button" value="false"/> (i had
already written the tile that displays the help button to branches on that
variable for the admin part of the site). Smooooov.
> -----Original Message-----
> From: Charles McClain [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 20, 2002 7:04 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Re-using JSP pages -- Follow-up
>
>
> Thanks, Martin.
>
> It's good to have the Tiles vs. Templates confusion cleared up, even
> though it seems I guessed wrong earlier. Thankfully -- from what you
> say -- the learning time I spent wasn't a complete waste.
> I'll dig into
> Tiles and convert my JSPs over.
>
> -----Original Message-----
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 20, 2002 3:55 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Re-using JSP pages -- Follow-up
>
>
>
>
> > -----Original Message-----
> > From: Charles McClain [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 20, 2002 10:46 AM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Re-using JSP pages -- Follow-up
> >
> >
> > Chris:
> >
> > As I plowed my way through converting my app to Struts, I had
> > to skim a
> > lot of the capabilities and make (hopefully, educated) guesses as to
> > which ones spend learning time on and subsequently use.
> >
> > In my early skimming, I looked at both Struts Tiles and Struts
> > Templates, which seemed at first glance to overlap quite a bit. I
> > chose to use Struts Templates, because it looked easier and the
> > example was easier to crib from, and figured that after I
> had mastered
>
> > everything else (Ha!) I could revisit this decision.
> >
> > As I started to apply the solution you gave me, I realized
> > that my JSPs
> > were becoming way too complicated -- littered with
> logic:equal tags --
> > and that a better way to approach it might be a slightly more
> > elaborate
> > template-based solution that constructs the page from more
> and smaller
> > components. That would give me several benefits:
> >
> > -- My mappings could still refer to the same JSP;
> > -- The template could assemble the page components based on
> > the value of
> > the "dispatch" request parameter, eliminating the need for
> the JSP to
> > know what formBean it had been passed (or rather, it would
> > automatically
> > know, because it would be an operation-specific page component);
> > -- The main component containing all of the html:text tags
> > for the form
> > properties would remain unchanged, since the html:text tag doesn't
> > require a "name" attribute.
>
> Another big benefit is that you'll avert (or at least greatly delay)
> disaster when you suddenly discover that your JSP pages are
> too big for
> the Java compiler to handle, and you're then forced to split the pages
> up. In my experience, this always happens right at the most critical
> time in your project, when you have no time to spare for fighting the
> compiler. ;-)
>
> >
> > So, my follow-up question, if you have time: Do you know
> enough about
>
> > Struts Tiles and Struts Templates to recommend one versus
> the other?
> > If I'm going to put in the time to break these JSPs into smaller
> > components
> > and use a Struts facility to assemble them, I'd sure like
> to know that
> > I'm using the "right" Struts facility and not spinning wheels.
>
> I would recommend that you go with Tiles. It's being actively
> developed
> and supported, whereas the original template taglib is more
> or less just
> being kept around for backwards compatibility. (Bugs will
> still be fixed
> in it, though, if any are found.)
>
> One thing to note is that everything that the original template taglib
> does can be done in Tiles, using the same tag and attribute names, so
> switching over is extremely easy.
>
> --
> Martin Cooper
>
>
> >
> > Don't get me wrong -- your solution to my original problem is very
> > useful, and it's nice to know that I have the option to do
> it that way
>
> > if I choose.
> >
> > -----Original Message-----
> > From: Bartley, Chris P [PCS] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 20, 2002 1:06 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Re-using JSP pages -- Follow-up
> >
> >
> > Hey, great! Glad it worked.
> >
> > I guess i should clarify, however, that what i sent is *a*
> > solution and
> > not necessarily the only or best solution. :)
> >
> > I haven't made the transition to Struts 1.1 yet, so there may
> > be a more
> > elegant way of solving this problem. Maybe one of the 1.1 gurus can
> > chime in here.
> >
> > Regarding the choice between a large number of simple JSP
> vs a small
> > number of complex ones, i'd recommend the former. If you haven't
> > looked into Tiles yet to help you manage your presentation, you
> > might give it a
> > whirl--very cool stuff.
> >
> > chris
> >
> > > -----Original Message-----
> > > From: Charles McClain [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, September 20, 2002 11:57 AM
> > > To: 'Struts Users Mailing List'
> > > Subject: RE: Re-using JSP pages -- Follow-up
> > >
> > >
> > > Thanks, Chris:
> > >
> > > I tested your proposed solution very quickly -- just
> > printing out the
> > > retrieved formName on my JSP -- and it does work.
> > >
> > > I'm surprised, though, that it isn't easier than that; it
> seems that
>
> > > the formName should be available via the bean:struts tag, or
> > some similar
> > > tag.
> > >
> > > Now I have to integrate the solution into my app. Like many
> > > newcomers, I'm wavering back and forth between having a
> large number
>
> > > of very simple
> > > JSPs, or a small number of more complex JSPs. It's nice to
> > know that,
> > > using your solution, I at least have the option.
> > >
> > > -----Original Message-----
> > > From: Bartley, Chris P [PCS] [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, September 20, 2002 12:19 PM
> > > To: 'Struts Users Mailing List'
> > > Subject: RE: Re-using JSP pages -- Follow-up
> > >
> > >
> > > Something like this might work:
> > >
> > > <bean:define id="actionMappingForThisScreen"
> > > name="org.apache.struts.action.mapping.instance"
> > > type="org.apache.struts.action.ActionMapping"/>
> > > <bean:define id="formName" name="actionMappingForThisScreen"
> > > property="name" type="java.lang.String" /> <bean:define
> > id="formBean"
> > > name="<%= formName %>"
> type="org.apache.struts.action.ActionForm"/>
> > >
> > > I haven't tested it, but i *think* it'll work since i *think* the
> > > current action mapping is stored in the request under the key
> > > "org.apache.struts.action.mapping.instance". The above
> code should
> > > help you get the form bean's name and a reference to the
> > bean itself.
> > >
> > > chris
> > >
> > > > -----Original Message-----
> > > > From: Charles McClain [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, September 20, 2002 11:13 AM
> > > > To: Struts User Mailing List
> > > > Subject: Re-using JSP pages -- Follow-up
> > > >
> > > >
> > > > All:
> > > >
> > > > This is a follow-up to my earlier post on the same topic.
> > > Although I
> > > > received a response, I think it wasn't the response I
> > > needed because I
> > >
> > > > didn't ask my question correctly.
> > > >
> > > > Boiled down -- and ignoring all the background of why I
> > > need it, which
> > >
> > > > may have confused people -- I want:
> > > >
> > > > -- To pass different form-beans to the same JSP;
> > > > -- To have the JSP figure out the name of the form-bean it
> > > > received, so it can use that form-bean name in various tags.
> > > >
> > > > I'm sure the form-bean name must be easily available to the
> > > JSP, but I
> > >
> > > > have searched the Struts User Guide and the taglib
> > > documentation, and
> > > > I can't figure out how . Can anyone help?
> > > >
> > > > Thanks again in advance. You guys were very responsive
> > > before; I just
> > >
> > > > needed to phrase my question more simply.
> > > >
> > > > Charles McClain
> > > > Phone: 603.659.2046
> > > > email: [EMAIL PROTECTED]
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > > <mailto:[EMAIL PROTECTED]>
> > >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
