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=".tile.name" ...
where .tile.name 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.
L.
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 <[EMAIL PROTECTED]> 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="http://struts.apache.org/tags-tiles-
> 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:
http://struts.apache.org/struts-sandbox/tiles/index.html
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
