On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 4/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> >
> > On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > According to the APIs, it is actually one Controller per Tile, not one
> > > Controller per page ... doesn't that give you (Michael) the hook you'd
> > need
> > > to grab the dynamic data for each fragment?
> >
> > I guess it does. But how is this better/different than simply
> > including Struts actions or any other resources?
>
> I found a pointer to Cedric's old web site[1] from the days before Tiles was
> contributed into Struts. The "advanced features" link there has some
> extended discussion of controllers (as well as a bunch of the other features
> of Tiles).
I've looked at this doc. If I undertand it correctly, a tile is this
whole thing:
<tiles:insert page="layout.jsp"
controllerClass="org.acme.TestTileController" >
<tiles:put name="title" value="Test controller set in insert" />
<tiles:put name="header" value="header.jsp" />
<tiles:put name="body" value="body.jsp" />
</tiles:insert>
I can have only one controller per tile, but I cannot have controllers
for, say, header.jsp or body.jsp separately. This is what I had in
mind and Greg Reddin got me right. I would prefer if something like
this was possible:
<tiles:insert page="layout.jsp" controller="/TestTileController.do" >
<tiles:put name="title" value="Test controller set in insert" />
<tiles:put name="header" value="/header.do" />
<tiles:put name="body" value="/body.do" />
</tiles:insert>
In this case header and body can be separate independent entities. I
believe that in most cases a composite page is built from only one
tile, so this would make real sense.
Reading further, section 5.2.2 One Controller - Multiple Views:
"Sometimes, the controller does some kind of logic and depending of
some result selects the appropriate view to render data. For example,
the controller processes user requests, if all is ok, data is shown,
if an error occurs, the appropriate error page is shown.
The current Tiles version doesn't directly support one controller
associated to multiple views, but this can be done with Struts' Action
Forward mechanism.
The solution consists of writing a Tile with its attributes (insert or
definition), and specify a Struts Action as page URL instead of a JSP
page. The action plays the role of the controller and then forwards to
the appropriate JSP page, which can either be an URL or a definition
name."
The action mapping follows:
<action path="/actionAsController"
type="org.apache.struts.example.tiles.ActionAsController">
<forward name="failure" path="/failurePage.jsp"/>
<forward name="success" path="success.definition"/>
</action>
What? How this is different from simply including
"/actionAsController.do" and then forwarding to an appropriate JSP
fragment? The problem here is that forwarding (to a JSP fragment) from
an included resource does not work, as I learned a year ago. While
this pattern does not work with <jsp:include>, Paul Benedict reported
that it works with <c:import>. I don't know how exactly JSTL handles
it, but if it works, than what is the difference from above Tiles
example? Granted, there was no JSTL in 2001. But there is now.
Going further to section 8, Advanced Usages. It talkes about
components. Here is the example:
<tiles:insert page="/tutorial/invoice/editAddress.jsp" >
<tiles:put name="property" value="shippingAddress" />
<tiles:put name="bean" beanName="invoiceForm" />
</tiles:insert>
How is that really different from
<jsp:include page="/tutorial/invoice/editAddress.jsp" >
<c:set name="property" value="shippingAddress" scope="request"/>
<c:set name="bean" value="invoiceForm" scope="request"/>
</jsp:include>
Is not this similar to above Tiles sample?
Again, I am not bashing Tiles, I am just looking for justification of
using it in a new project now in 2006, when we have pretty solid CSS
implementation in browsers, better XTML/CSS knowledge overall, and
JSTL.
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
