FAQ

[Struts-user] [shale] reusable parameterized snippets in Tiles/Clay/Facelets

Rogers Reilly
Feb 5, 2006 at 3:26 am
Hi,

We're refactoring the view layers of a couple medium-sized projects from
hodgepodge JSP to JSF/Shale, and are trying to choose a templating
option to stick on top. My first thought was to just do Tiles, but I
quickly ran into trouble when trying to parameterize a small Tile with
JSF components inside. I'm able to "put" a bean into my Tile, but
<tiles:importAttribute /> is only making the bean available to Tiles
tags, not to JSF #{bean.xxx} accessors inside (and even if I were to get
the sucker in somehow, I'd be nervous about it referencing the same JSF
stuff once it got passed through Tiles).

So I hit the web and found Clay and Facelets (which being native JSF
technologies I assume would knock out that last concern). I'm not
asking anyone to tell me one's better than the other; rather, I've got a
specific use case I'd like to understand in Clay. Unfortunately I
haven't found any documentation about it online, apart from David Geary
describing Clay as "a way to parameterize a JSP page for different
managed beans" in his weblog. (after demo'ing the Tapestry-esque HTML
stuff, he then says, "I haven't even shown you how to implement
parameterized subtrees." :-( )

What I need is to define a short JSP (call it snippet.jsp) along these
lines:
<h:outputText value="#{storyBean.title}" />
<h:outputText value="#{authorBean.byline}" />
<h:outputText value="#{storyBean.body}" />

and then reuse it in many different pages a la:
<clay:clay jsfid="snippet_jsp" storyBean="#{backingBean.story}"
authorBean="#{backingBean.author}" />

Ideally I'd be able to do this inside a c:forEach loop as well ... which
I've heard is hairy in JSF. Anyway, as I said, I haven't been able to
track down any examples of somebody doing this. The Apache docs
<http://struts.apache.org/struts-shale/features-reusable-views.html>
make it sound like the most you can do is define a Clay component that
extends an existing JSF tag and then resuse /that /all over the place,
which is fine, but I really need to define a whole chunk of
parameterized code. I don't see any kind of "path" attribute, so maybe
to implement this, I would have to implement my own custom component and
then wrap it in a Clay jsfid--at which point, I might as well just use
the custom tag over and over. (I should mention that snippet.jsp won't
actually be that simple, so a canned datalist component isn't going to
cut it.)

I know this type of thing can be done in Facelets (see code below), but
my preference is to stay within Shale if possible. Can anybody point me
to any example of parameterized snippets along these lines? David's
general description of Clay in his weblog made it sound like exactly
what I was looking for, but I haven't been able to nail down the params
functionality.

Thanks in advance.
-Rogers

here's an example of snippet/parameter usage in Facelets, if it
enlightens my rambling above at all ...
<!-- include.xhtml -->
...
<span id="leftNav">
<ui:include src="/WEB-INF/siteNav.xhtml">
<ui:param name="menuBean" value="#{backingBean.options}"/>
</ui:include>
</span>
...|
<!-- siteNav.xhtml -->
...
<ui:composition>
<!-- myfaces tomahawk components -->
<t:tree2 value="#{menuBean}" var="opt">
...
</t:tree2>
</ui:composition>
...|




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
reply

Search Discussions

2 responses

  • Gary VanMatre at Feb 5, 2006 at 4:25 pm

    From: Rogers Reilly <rogers_reilly@s-rod.com>

    Hi,

    So I hit the web and found Clay and Facelets (which being native JSF
    technologies I assume would knock out that last concern). I'm not
    asking anyone to tell me one's better than the other; rather, I've got a
    specific use case I'd like to understand in Clay. Unfortunately I
    haven't found any documentation about it online, apart from David Geary
    describing Clay as "a way to parameterize a JSP page for different
    managed beans" in his weblog. (after demo'ing the Tapestry-esque HTML
    stuff, he then says, "I haven't even shown you how to implement
    parameterized subtrees." :-( )
    The Clay documentation is being worked on (by David Geary) but I can assure you it will be worth the wait.

    The best reference is the usecase examples. The "symbols" usecase shows how to use Clay like tiles. There is a generic layout that has several areas, header, footer, left nav and content. There are three pages that plug in different content into the layouts. Two of the examples, "page1" and "page2" use full XML views as the page entry point. The third example uses a full HTML view.

    A limitation that Clay has is that you cannot include a JSP fragment from within a Clay subtree. This has to do with how the JSP tags keep track of the last component and it's not standardized between JSF runtimes.

    What I need is to define a short JSP (call it snippet.jsp) along these
    lines:


    <h:outputText value="#{storyBean.title}" />
    <h:outputText value="#{authorBean.byline}" />
    <h:outputText value="#{storyBean.body}" />
    >

    Clay will not allow you to do this kind of parameter substitution within a JSP page. However, it can be done in a XML or HTML view.

    The root of the subtree needs to be a Clay component. So, if you are using JSP, the rest of the parameterized subtree must be HTML or XML views.

    and then reuse it in many different pages a la:
    <clay:clay jsfid="snippet_jsp" storyBean="#{backingBean.story}" authorBean="#{backingBean.author}" />
    Symbols are used within a JSP similar to the JSF attributes tag.
    <clay:clay jsfid="/snippet.html">
    <clay:symbol name="storyBean" value="#{backingBean.story}" />
    <clay:symbol name="authorBean" value="#{backingBean.author}" />
    </:clay:clay>
    In an HTML view, the symbols are the html attributes that are not defined as component attributes in the target component.
    <span jsfid="/snippet.html" storyBean="#{backingBean.story}" authorBean="#{backingBean.author}" />
    Or, in a full xml or common xml config.
    <component jsfid="basePage" extends="clay" >
    <attributes>
    <set name="clayJsfid" value="/snippet.html"/>
    </attributes>
    <symbols>
    <set name="authorBean" value="#{backingBean.author}"/>
    </symbols>

    Ideally I'd be able to do this inside a c:forEach loop as well ... which
    I've heard is hairy in JSF. Anyway, as I said, I haven't been able to
    track down any examples of somebody doing this. The Apache docs
    JSF 1.2 has the JSP fix for interweaving JSP with JSF/JSP. Myfaces/Tomahawk has a dataList JSF component that will stack-up to the JSTL foreach. Clay also has a clayForEach component but it only works within HTML views.
    make it sound like the most you can do is define a Clay component that
    extends an existing JSF tag and then resuse /that /all over the place,
    which is fine, but I really need to define a whole chunk of
    parameterized code.
    Clay was originally targeted for JSF/JSP component reuse. The scope grew with the creation of symbols and we realized that a html fragment could became a Clay component. At this point the scope mushroomed into components that represented view fragments that could be defined in xml, html and at runtime.
    I don't see any kind of "path" attribute, so maybe
    to implement this, I would have to implement my own custom component and
    then wrap it in a Clay jsfid--at which point, I might as well just use
    the custom tag over and over. (I should mention that snippet.jsp won't
    actually be that simple, so a canned datalist component isn't going to
    cut it.)
    The jsfid represents a component definition in clay. The suffix of the jsfid is used to determine the type of resource (like a Win file association). A html view fragment would be represented like this:
    jsfid="/symbols/page3.html"

    Clay also has something similar to a tiles xml definition. The entry point of the application points to a abstract page definition. The Clay XML definition allows for metadata inheritance using the extends attribute. It also allows you to define symbols that can be used to inject customizations to a clay managed view.

    I know this type of thing can be done in Facelets (see code below), but
    my preference is to stay within Shale if possible. Can anybody point me
    to any example of parameterized snippets along these lines? David's
    general description of Clay in his weblog made it sound like exactly
    what I was looking for, but I haven't been able to nail down the params
    functionality.
    The shale symbols usecase would be the best place to start.
    http://svn.apache.org/builds/struts/nightly/struts-shale/shale-usecases-20060205.war

    Ryan Wynn recently posted the best Clay example yet. I'm trying to get the support of a Struts PMC member to pull it down into a clay example.

    http://issues.apache.org/bugzilla/show_bug.cgi?id=38298

    Hope that gets you started.


    Gary
    Thanks in advance.
    -Rogers

    here's an example of snippet/parameter usage in Facelets, if it
    enlightens my rambling above at all ...
    ...





    ...|
    ...



    ...


    ...|




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Rogers Reilly at Feb 5, 2006 at 7:32 pm
    Thanks for the response (and for Clay!), Gary- this is exactly what I
    needed. I'll have a look at the use cases.

    Gary VanMatre wrote:
    From: Rogers Reilly <rogers_reilly@s-rod.com>

    Hi,

    So I hit the web and found Clay and Facelets (which being native JSF
    technologies I assume would knock out that last concern). I'm not
    asking anyone to tell me one's better than the other; rather, I've got a
    specific use case I'd like to understand in Clay. Unfortunately I
    haven't found any documentation about it online, apart from David Geary
    describing Clay as "a way to parameterize a JSP page for different
    managed beans" in his weblog. (after demo'ing the Tapestry-esque HTML
    stuff, he then says, "I haven't even shown you how to implement
    parameterized subtrees." :-( )

    The Clay documentation is being worked on (by David Geary) but I can assure you it will be worth the wait.

    The best reference is the usecase examples. The "symbols" usecase shows how to use Clay like tiles. There is a generic layout that has several areas, header, footer, left nav and content. There are three pages that plug in different content into the layouts. Two of the examples, "page1" and "page2" use full XML views as the page entry point. The third example uses a full HTML view.

    A limitation that Clay has is that you cannot include a JSP fragment from within a Clay subtree. This has to do with how the JSP tags keep track of the last component and it's not standardized between JSF runtimes.



    What I need is to define a short JSP (call it snippet.jsp) along these
    lines:


    <h:outputText value="#{storyBean.title}" />
    <h:outputText value="#{authorBean.byline}" />


    <h:outputText value="#{storyBean.body}" />


    Clay will not allow you to do this kind of parameter substitution within a JSP page. However, it can be done in a XML or HTML view.

    The root of the subtree needs to be a Clay component. So, if you are using JSP, the rest of the parameterized subtree must be HTML or XML views.



    and then reuse it in many different pages a la:
    <clay:clay jsfid="snippet_jsp" storyBean="#{backingBean.story}" authorBean="#{backingBean.author}" />
    Symbols are used within a JSP similar to the JSF attributes tag.
    <clay:clay jsfid="/snippet.html">
    <clay:symbol name="storyBean" value="#{backingBean.story}" />
    <clay:symbol name="authorBean" value="#{backingBean.author}" />
    </:clay:clay>
    In an HTML view, the symbols are the html attributes that are not defined as component attributes in the target component.
    <span jsfid="/snippet.html" storyBean="#{backingBean.story}" authorBean="#{backingBean.author}" />
    Or, in a full xml or common xml config.
    <component jsfid="basePage" extends="clay" >
    <attributes>
    <set name="clayJsfid" value="/snippet.html"/>
    </attributes>
    <symbols>
    <set name="authorBean" value="#{backingBean.author}"/>
    </symbols>



    Ideally I'd be able to do this inside a c:forEach loop as well ... which
    I've heard is hairy in JSF. Anyway, as I said, I haven't been able to
    track down any examples of somebody doing this. The Apache docs

    JSF 1.2 has the JSP fix for interweaving JSP with JSF/JSP. Myfaces/Tomahawk has a dataList JSF component that will stack-up to the JSTL foreach. Clay also has a clayForEach component but it only works within HTML views.


    make it sound like the most you can do is define a Clay component that
    extends an existing JSF tag and then resuse /that /all over the place,
    which is fine, but I really need to define a whole chunk of
    parameterized code.
    Clay was originally targeted for JSF/JSP component reuse. The scope grew with the creation of symbols and we realized that a html fragment could became a Clay component. At this point the scope mushroomed into components that represented view fragments that could be defined in xml, html and at runtime.


    I don't see any kind of "path" attribute, so maybe
    to implement this, I would have to implement my own custom component and
    then wrap it in a Clay jsfid--at which point, I might as well just use
    the custom tag over and over. (I should mention that snippet.jsp won't
    actually be that simple, so a canned datalist component isn't going to
    cut it.)

    The jsfid represents a component definition in clay. The suffix of the jsfid is used to determine the type of resource (like a Win file association). A html view fragment would be represented like this:
    jsfid="/symbols/page3.html"

    Clay also has something similar to a tiles xml definition. The entry point of the application points to a abstract page definition. The Clay XML definition allows for metadata inheritance using the extends attribute. It also allows you to define symbols that can be used to inject customizations to a clay managed view.



    I know this type of thing can be done in Facelets (see code below), but
    my preference is to stay within Shale if possible. Can anybody point me
    to any example of parameterized snippets along these lines? David's
    general description of Clay in his weblog made it sound like exactly
    what I was looking for, but I haven't been able to nail down the params
    functionality.

    The shale symbols usecase would be the best place to start.
    http://svn.apache.org/builds/struts/nightly/struts-shale/shale-usecases-20060205.war

    Ryan Wynn recently posted the best Clay example yet. I'm trying to get the support of a Struts PMC member to pull it down into a clay example.

    http://issues.apache.org/bugzilla/show_bug.cgi?id=38298

    Hope that gets you started.


    Gary


    Thanks in advance.
    -Rogers

    here's an example of snippet/parameter usage in Facelets, if it
    enlightens my rambling above at all ...
    ...





    ...|
    ...



    ...


    ...|




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org

Related Discussions

Discussion Navigation
viewthread | post

2 users in discussion

Rogers Reilly: 2 posts Gary VanMatre: 1 post