Stripes

Nested layouts: allow enclosing layout-render tag to layout components within a nested layout-definition (not just its own layout-definition)

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: Release 1.4.2
  • Fix Version/s: Release 1.5.7
  • Component/s: Tag Library
  • Labels:
    None

Description

I've hit a small but annoying limitation with nesting layout-definition tags.

Lets say I create a new layout-definition file (/layout/special.jsp) that renders the /layout/default.jsp definition like so:

<layout-definition>
<layout-render name="/layout/default.jsp">
<layout-component name="contents">
<div id="imspecial">
${somethingSpecial} <%-- comming from a layout-component in enclosing tag--%>
</div>
</layout-component>
</layout-render>
</layout-definition>

This works only in the situation where the enclosing tag only lays out the "somethingSpecial" component. There is no way to override or layout any of the "default.jsp" components such as header or footer.

My suggestion (and patch) is that when a layout-render tag is within a layout-definition tag, the context of the layout-definition should override the context of the layout-render tag. This would move layout-components and parameters "downstream" into embedded layout-definitions until one of them renders it. I find that it makes layout-definitions easier to "extend".

This might not find within the tags initial intent. If such an improvement is not possible, I'd like to know what are the best-practices when nesting layouts or event an alternative solutions to nesting...

Activity

Hide
Philippe Laflamme added a comment - 04/Dec/06 5:56 PM

A patch that overrides a layout-render tag's context with its layout-definiton parent tag's context.

Show
Philippe Laflamme added a comment - 04/Dec/06 5:56 PM A patch that overrides a layout-render tag's context with its layout-definiton parent tag's context.

People

Vote (2)
Watch (1)

Dates

  • Created:
    04/Dec/06 5:56 PM
    Updated:
    Today 10:01 AM
    Resolved:
    Today 10:01 AM