CODEWITHSUNDEEP
jsfxhtmlfacelets
Steve Atkinson
Steve Atkinson

Reputation: 1239

Strange jsf ui:include behaviour

This one is a real head scratcher... I have a number of command links which are styled as buttons so in order to enable easy maintenance, I have written a little html fragment that I can include with some parameters to render a nicely styled command link.

Now this works great except when the action outcome is to change view, at which point, the "include" version steadfastly refuses to obey the click to navigate and I have no idea why! If the action results in a validation error, the errors are shown so the action is definitely being called - and my logs confirm this, however, if there are no validation errors, the original version, without using the include, will navigate to the next page just fine, but the version using include will not navigate. I have tried with a very simple "hello.xhtml" page as the second page so I know it can't be anything to do with the contents of the new view.

Edited for clarity: I use several buttons on the page, most of which just modify the state of the current page and these are all working fine. It's only when the outcome is to change view that things go wrong with the "include" version.

I'm running JSF 1.2 on top of Portal Server 6.1/WAS 7.0

I've spent too long trying to figure this out so over to you guys to see if you have any ideas...

Update: To save wading through the comments, the answer is I was using from-action in my navigation rules, which just matches the string used in the commandLink - so the navigation handler was seeing #{bean[action]} as the from-action rather than #{applicationPage.doContinue}

Some code.

My button template:

<ui:composition xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets" xml:lang="en" lang="en">

    <ui:remove>
        Functional Button with arrow icon.
        Parameters:
        linkId           = The id for the commandLink.
        linkText         = The text to display on the button.
        linkTitle        = title text to display
        bean             = The bean name containing the action handler.
        action           = The action handler to call.
    </ui:remove>
    <div class="btn functionalButton">
        <h:commandLink id="#{linkId}" action="#{bean[action]}" title="#{linkTitle}" styleClass="functional">
                #{linkText}
                <span class="arrow icon" />
            <span class="tl" />
            <span class="tr" />
            <span class="bl" />
            <span class="br" />
        </h:commandLink>
    </div> 

</ui:composition>

And an example of use on a page:

<ui:include src="/WEB-INF/facelets/content/functionalButton.xhtml">
    <ui:param name="linkId" value="applicationSubmit" />
    <ui:param name="bean" value="#{applicationPage}" />
    <ui:param name="action" value="doContinue" />
    <ui:param name="linkText" value="#{msg['button_FF060_continue']} " />
</ui:include>

This version won't change view.

Prior to using the include, the code looked like this (which should resolve and render to the exact same html) and yet this version changes view just fine.

<div class="btn functionalButton">
    <h:commandLink id="applicationSubmit" styleClass="functional" action="#{applicationPage.doContinue}" title="#{msg['button_FF060_continue']}">
     #{msg['button_FF060_continue']} 
        <span class="arrow icon" id="arrow_continue" />
        <span class="tl" />
        <span class="tr" />
        <span class="bl" />
        <span class="br" />
    </h:commandLink>
</div>

Upvotes: 1

Views: 1644

Answers (1)

BalusC
BalusC

Reputation: 1108577

Update: that can happen when the <from-action> in your <navigation-case> associated with the action still references the original EL expression like so:

<from-action>#{applicationPage.doContinue}</from-action>

It's not been interpreted as the actual method expression, but as a string literal, exactly the one which you definied in action attribute. So when using an include/tag file, you should change it to the literal EL expression as you used in action attribute:

<from-action>#{bean[action]}</from-action>

Or maybe better, just remove it. It's not useful if you don't have multiple actions which can each possibly return the same outcome but need a different destination. I'd also suggest to use just the <to-view-id> without extension as outcome value. This eases future migration to JSF 2.0 as that would already implicitly be done.



Original answer below is kept for future reference

I'm not sure, but probably Facelets 1.x simply doesn't eat that. This works for Facelets 2.x. I only can't tell from experience as I've never (ab)used an include file this way.

I'd recommend using it as a tag file instead. Additional benefit is that this also ends up in clearer syntax and the possibility to provide attribute names and descriptions in IDE autocomplete. All you need to do is to create a /META-INF/my.taglib.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE facelet-taglib PUBLIC
    "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
    "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">

<facelet-taglib>
    <namespace>http://example.com/jsf/facelets</namespace>
    <tag>
        <tag-name>functionalButton</tag-name>
        <source>/WEB-INF/facelets/content/functionalButton.xhtml</source>
    </tag>
</facelet-taglib>

(definition of attributes is optional, if you want, add it as <attribute> inside <tag>, I'd also recommend placing those files in some /tags subfolder e.g. /WEB-INF/facelets/tags)

If you register it in /WEB-INF/web.xml as follows

<context-param>
    <param-name>facelets.LIBRARIES</param-name>
    <param-value>/META-INF/my.taglib.xml</param-value>
</context-param>

Then you'll be able to use it as follows:

xmlns:my="http://example.com/jsf/facelets"
...
<my:functionalButton linkId="applicationSubmit" bean="#{applicationPage}" 
    action="doContinue" linkText="#{msg['button_FF060_continue']} " />

Upvotes: 1

Related Questions