struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laurie Harper <>
Subject Re: Too many moving parts in Tiles
Date Wed, 25 Oct 2006 22:04:03 GMT
Chris Pratt wrote:
> Hmmm, I'm not using Tiles alone or Struts 2.  I'm using the Tiles 
> integrated
> into Struts 1.2.9.  I've tried using the ForwardAction to forward something
> like:
>    <action path="/loginPage.jsp" parameter="login.layout" type="
> org.apache.struts.actions.ForwardAction"/>
> But it doesn't work, it just returns 404's.

You probably want something like

   <action path="" ...

where is the name of a definition in your tiles-defs.xml. You 
definitely don't need the 2-line JSP when using Tiles with Struts like this.


> As far as 2 definitions per page, I've been told by others on the list that
> because you can only define variables at the first level (or something like
> that) that you have to separate the layout from the definition into two
> definitions.  It seems very kludgy to me, which is why I'm asking here.  I
> agree that the ability to nest and extend Tiles is an excellent idea, 
> but if
> this is the "best practice" approach, it leaves a lot to be desired.
> I've tried implementing it the way I'd like it to work, and with help from
> people on the list, this was the only way I could get it to work, so my
> wishes are a bit moot at this point.
> I'm just trying to get a handle on this "simplifying" technology and make
> sure I'm not making things harder than they should be.  If anyone can point
> to a simpler solution (using Tiles and Struts, please refrain from
> suggesting "switch to a completely different package"), I'd be very
> grateful.
>  (*Chris*)
> On 10/24/06, Greg Reddin <> wrote:
>> On Oct 24, 2006, at 12:20 PM, Chris Pratt wrote:
>> > First I have to create
>> > an essentially empty file for each page that uses Tiles, something
>> > like:
>> >
>> > <%@ taglib prefix="tiles" uri="
>> > el"%>
>> > <tiles:insert definition="login.pane"/>
>> First off, I'm assuming you're using Tiles 2?  That may affect the
>> way we answer the rest of your questions.
>> This is a drawback to using Tiles in standalone mode.  Tiles is meant
>> to be inserted into the view layer of an MVC application.  It is
>> meant to interface with the controller component of an MVC
>> framework.  So, if you're using Struts or JSF, you'd configure your
>> controller layer to forward requests to Tiles.  Instead of a 2-line
>> JSP page along with a Tile definition and associated pages for every
>> "page" you'd have 2 lines of configuration in your controller layer
>> along with the Tiles components for every page.  But in standalone
>> mode you don't have a front controller so your intermediate JSP page
>> becomes the front controller.  In my current project I'm using
>> Facelets.  I'd like to see Tiles implement a feature of Facelets in
>> which the "page" calls the template.  Tiles works the other way
>> around.  In Tiles you have to define a definition that references
>> both the template and the page content.  In Facelets you invoke a
>> page that, in turn, pulls in a template.
>> But Tiles is currently missing this feature.  Maybe you should
>> consider including a controller in your app to avoid this problem.
>> Currently, there is no Struts 1.x support for Tiles 2, but there is
>> Struts 2 and JSF (by way of Shale) support.  Note that I haven't used
>> either in an application yet.
>> > Then since 90% of our files are separated into a blue section (with
>> > breadcrumbs) at the top of the page and a white section at the
>> > bottom, I
>> > extended the main layout definition to add those tiles.  But to
>> > extend a
>> > tile it apparently takes two definitions (which doesn't make any
>> > sense to
>> > me):
>> >
>> >  <definition name="default.pane" extends="site.layout">
>> >    <put name="body" value="default.layout" type="definition"/>
>> >  </definition>
>> >
>> >  <definition name="default.layout" path="default-layout.jsp">
>> >    <put name="bluearea" value="/tiles/blank.jsp" type="page"/>
>> >    <put name="whitearea" value="/tiles/blank.jsp" type="page"/>
>> >    <putList name="breadcrumbs">
>> >      <add value="/|head.home" type="string"/>
>> >    </putList>
>> >  </definition>
>> The above defines the frame of your template, but you don't have to
>> provide 2 defs for every page do you?  For example, for a "foobar"
>> page you only need the following (plus the intermediate JSP page),
>> correct?
>> <definition name="foobar" extends="default.layout">
>>    <put name="bluearea" value="mybluearea.jsp"/>
>>    <put name="whitearea" value="mywhitearea.jsp"/>
>> </definition>
>> Or have I missed something?
>> I've heard talk of nested definitions whereby maybe you could combine
>> default.pane and default.layout into one, but I'm not sure if it
>> works or if it would be a best practice.  It might depend on who you
>> ask :-)  The fact that you can extend definitions is a good thing,
>> IMO, but you can only take the inheritance paradigm so far before it
>> breaks down when dealing with XML-based definitions.
>> > And since our site is internationalized we have externalized text in
>> > resources as well as internationalized tiles_defs_fr.xml files.  It
>> > seems
>> > like Tiles is making flow and maintainability harder not easier.
>> To this point, in some cases, you're probably correct.  It would be
>> helpful if you would think for a minute about how you might "like" it
>> to work.  If you can post some example defs and pages that would
>> represent your ideal environment we might be able to modify Tiles to
>> suit.    For example:
>> *  What would be your alternative to using the intermediate JSP?
>> *  What would be your alternative to using 2 extension defs to build
>> 90% of your pages?  (I know the answer is "one" def, but what would
>> it look like?)
>> With Tiles 2, we're still in development so, pretty much anything goes.
>> > Is there a
>> > best practice document somewhere that defines how to use this
>> > technology to
>> > make life easier rather than just making more work?
>> Well, the doc is in progress.  This is the best we can provide right
>> now:
>> I think we have some best practices in mind, we just haven't had a
>> chance to get them into the official docs yet.
>> Thanks,
>> Greg
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message