<definition name=".mainLayout" page="/tiles/mainLayout.jsp">
<parameter name="title" name="${title}"/>
<parameter name="body" name="${body}"/>
</definition>
<definition name=".subLayout" page="/tiles/subLayout.jsp">
<parameter name="subContent" value="${subContent}"/>
</definition>
<definition name=".subFoo" extends=".subLayout">
<parameter name="subContent" value="/tiles/subFoo.jsp"/>
</definition>
<definition name=".foo" extends=".mainLayout">
<parameter name="title" value="Foo title">
<parameter name="body" value=".subFoo"/>
</definition>This works perfectly without any importAttribute tricks and gives the right resulting JSP (.foo==>mainLayout.jsp, inserting .subFoo==>subLayout.jsp, finally inserting subFoo.jsp)
The problem is, this doesn't scale well--if I want to add more pages that use the same two-level layout I have to add *two* tiles defs for each (bar + subBar, baz + subBaz, etc.). It gets worse as your recursive tile insertion gets deeper. Note that the ".subFoo" definition is only referenced from one other tile definition (.foo) and never reused.
It seems like there should be some way to define tiles that tie recursive inserts together, as I was attempting to by defining .foo extends .nestedLayout extends .mainLayout. It *almost* worked except for the attribute-value environment scope.
Is there a better way to do this?
-- Bill
1. A tile is a retangular area in a JSP page sometimes referred to as a region.
2. Tiles are built recursively and can be represented as a tree (upside down, of course).
3. Each tree "node" is a tile or region.
4. The root node is usually the page.
5. Final nodes or "leaves" contain the page content. [This is not wholly accurate. You can have as much content on the way down the tree as you want.]
6. Layout nodes are utility tiles that position tiles within pages, i.e. they have INSERTs <tiles:insert> or provide background markup.
7. Tiles support features, including "parameters" or "ATTRIBUTES" and "DEFINITIONS".
8. Parameters are called "attributes" and accept variable information at RUNTIME.
9. Tile attributes are defined WHEN INSERTING THE TILE and are VISIBLE WITHIN THE TILE ONLY. (This avoids name conflicts.)
10. Tile attributes can be Strings or other types.
11. Definitions are a SET OF ATTRIBUTES (a SCREEN) which become a discrete object with its own IDENTITY.
12. You can create other screens from definitions. 13. Definitions are optional. You can deploy a tile using a simple JSP tag.
14. Definitions allow simple overloading of attributes that change.
15. A definition is like an <tiles:insert> tag with a NAME.
16. Because of the name, you can: OVERLOAD (additional or replacement attributes), EXTEND (using one definition as the base), and REUSED (by storing in a jsp file or an XML document), and useit as the TARGET of a Struts ActionForward.
Attributes:
1. Can be specified statically or an action can pass the value of an attribute to the tile at runtime.
Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
