tiles-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas LE BAS <m...@nlebas.net>
Subject Re: Help propagating attribute from view to templates
Date Tue, 24 Jan 2012 00:05:19 GMT
Hi!

On 12-01-23 05:19 PM, Dan Woodroffe wrote:
> I've verified that location.jsp is loading, but it seems the syntax I
> am using is incorrect.

The syntax is correct, it's just that location.jsp happens too late to 
change anything in header.jsp.

To keep it simple, this is what happens when you render the definition 
"location":
- Tiles looks for all declared attributes:
    * header = /WEB-INF/jsp/header.jsp (inherited from base.definition)
    * body = /WEB-INF/jsp/location.jsp (overriden)
- Tiles looks for the template of the definition (inherited from 
base.definition)
- Tiles renders the template /WEB-INF/jsp/layout.jsp
    * layout.jsp adds a new attribute "title" = Layout title
    * layout.jsp calls the attribute header (/WEB-INF/jsp/header.jsp).
       # header.jsp calls the attribute "title" at this time
    * layout.jsp calls the attribute body (/WEB-INF/jsp/location.jsp)
       # location.jsp adds a new attribute "title", but this is too late 
to be used in the header.

> I'm fully aware that I could place this title in the xml configuration
> for each page type, but there are multiple types of data I need to
> perpetuate through from location.jsp to the layout.jsp (and
> header.jsp), for example we have an in house jawr wrapper to achieve
> deferred javascript load and execution that references different files
> on a per page basis.

Well, anything you do in location.jsp will never be seen in header.jsp, 
sorry.

I'm not sure exactly why placing the title in the xml files is not an 
option for you.

My guess is you've designed location.jsp to work with sitemesh: 
location.jsp that produces all page-specific content, and then sitemesh 
is transforming parts of it based on its configured rules. The jawr 
wrapper would be to support jawr from sitemesh (googling for "sitemesh 
site:jawr.java.net" gives nothing, so that would explain why it's an 
in-house module).

Tiles works very differently from sitemesh. Instead of transforming an 
existing page, it builds the page step by step. That means you assemble 
several JSPs into a single page, and attributes should be known 
beforehand. For instance, you may need to write the attribute "title" in 
/html/head/title (from head.jsp) and again in /html/body/div[id='title'] 
(from layout.jsp). That's why we usually place the attributes in the xml 
configuration.

I don't know if I've guessed right, or if my explanation is clear enough 
or even that helps you at all. I'm sure tiles provides an elegant 
solution for what you're trying to achieve (and probably so does 
sitemesh in a different way), but I'm guessing a lot here.

Borrowing from what Antonio said earlier today, I'll close this message 
with an example of how jawr could work with Tiles without the need of in 
house dev:

tiles-def.xml

<definition name="base" template="...">
   <put-attribute name="title" value="Layout title" />
   <put-list-attribute name="scripts">
     <!-- the scripts that everybody needs -->
     <add-attribute value="script1.js" />
     <add-attribute value="script2.js" />
   </put-list-attribute>
</definition>
<definition name="location" extends="base">
   <put-attribute name="title" value="Location title" />
   <put-list-attribute name="scripts" inherit="true">
     <!-- add a new script for this page -->
     <add-attribute value="script_location.js" />
   </put-list-attribute>
</definition>

header.jsp

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://jawr.net/tags" prefix="jwr" %>
<tiles:importAttribute name="scripts" />
<head>
   <c:forEach var="scr" items="${scripts}">
     <jwr:script src="${scr.value}" />
   </c:forEach>
</head>

I hope I've helped you see a bit further through the fog...
Nick

Mime
View raw message