2

Suppose I want to navigate in my application, and include different facelet pages dynamically. I have a commandLink like this:

<h:commandLink value="Link" action="#{navigation.goTo('someTest')}">
    <f:ajax render=":content" />
</h:commandLink>

And this is where I include the facelet:

<h:form id="content">
    <ui:include src="#{navigation.includePath}" />
</h:form>

The Navigation class:

public class Navigation {
    private String viewName;

    public void goTo(String viewName) {
        this.viewName = viewName;
    }

    public String getIncludePath() {
        return resolvePath(viewName);
    }
}

I have seen similar examples, but this doesn't work of course. As ui:include is a taghandler, the include happens long before my navigation listener is invoked. The old facelet is included, instead of the new. So far I get it.

Now to the headache part: How can I dynamically include a facelet, based on an actionListener? I tried to include the facelet in a preRender event, and a phaseListener before RENDER_RESPONSE. Both work, but in the event listener I can't include a facelet which contains an other preRender event, and in the phaseListener I get duplicate Id's after some clicks in the included facelet. However, inspecting the component tree tells me, there are no duplicate components at all. Maybe these two ideas were not to good at all..

I need a solution, where the page with the ui:include, or the Java class which includes the facelet, doesn't have to know the pages, which will be included, nor the exact path. Did anybody solve this problem before? How can I do it?


I am using JSF 2.1 and Mojarra 2.1.15


All you need to reproduce the Problem is this bean:

@Named
public class Some implements Serializable {
    private static final long serialVersionUID = 1L;
    private final List<String> values = new ArrayList<String>();

    public Some() {
        values.add("test");
    }

    public void setInclude(String include) {
    }
    public List<String> getValues() {
        return values;
    }
}

This in your index file:

<h:head>
    <h:outputScript library="javax.faces" name="jsf.js" />
</h:head>

<h:body>
    <h:form id="topform">
        <h:panelGroup id="container">
            <my:include src="/test.xhtml" />
        </h:panelGroup>
    </h:form>
</h:body>

And this in text.xhtml

<ui:repeat value="#{some.values}" var="val">
    <h:commandLink value="#{val}" action="#{some.setInclude(val)}">
        <f:ajax render=":topform:container" />
    </h:commandLink>
</ui:repeat>

That's enough to produce an error like this:

javax.faces.FacesException: Cannot add the same component twice: topform:j_id-549384541_7e08d92c
Bruno Schäpper
  • 1,220
  • 1
  • 13
  • 20

1 Answers1

3

For OmniFaces, I've also ever experimented with this by creating an <o:include> as UIComponent instead of a TagHandler which does a FaceletContext#includeFacelet() in the encodeChildren() method. This way the right included facelet is remembered during restore view phase and the included component tree only changes during render response phase, which is exactly what we want to achieve this construct.

Here's a basic kickoff example:

@FacesComponent("com.example.Include")
public class Include extends UIComponentBase {

    @Override
    public String getFamily() {
        return "com.example.Include";
    }

    @Override
    public boolean getRendersChildren() {
        return true;
    }

    @Override
    public void encodeChildren(FacesContext context) throws IOException {
        getChildren().clear();
        ((FaceletContext) context.getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY)).includeFacelet(this, getSrc());
        super.encodeChildren(context);
    }

    public String getSrc() {
        return (String) getStateHelper().eval("src");
    }

    public void setSrc(String src) {
        getStateHelper().put("src", src);
    }

}

Which is registered in .taglib.xml as follows:

<tag>
    <tag-name>include</tag-name>
    <component>
        <component-type>com.example.Include</component-type>
    </component>
    <attribute>
        <name>src</name>
        <required>true</required>
        <type>java.lang.String</type>
    </attribute>
</tag>

This works fine with the following view:

<h:outputScript name="fixViewState.js" />

<h:form>
    <ui:repeat value="#{includeBean.includes}" var="include">
        <h:commandButton value="Include #{include}" action="#{includeBean.setInclude(include)}">
            <f:ajax render=":include" />
        </h:commandButton>
    </ui:repeat>
</h:form>

<h:panelGroup id="include">
    <my:include src="#{includeBean.include}.xhtml" />
</h:panelGroup>

And the following backing bean:

@ManagedBean
@ViewScoped
public class IncludeBean implements Serializable {

    private List<String> includes = Arrays.asList("include1", "include2", "include3");
    private String include = includes.get(0);

    private List<String> getIncludes() {
        return includes;
    }

    public void setInclude(String include) {
        return this.include = include;
    }

    public String getInclude() { 
        return include;
    }

}

(this example expects include files include1.xhtml, include2.xhtml and include3.xhtml in the same base folder as the main file)

The fixViewState.js can be found in this answer: h:commandButton/h:commandLink does not work on first click, works only on second click. This script is mandatory in order to fix JSF issue 790 whereby the view state get lost when there are multiple ajax forms which update each other's parent.

Also note that this way each include file can have its own <h:form> when necessary, so you don't necessarily need to put it around the include.

This approach works fine in Mojarra, even with postback requests coming from forms inside the include, however it fails hard in MyFaces with the following exception during initial request already:

java.lang.NullPointerException
    at org.apache.myfaces.view.facelets.impl.FaceletCompositionContextImpl.generateUniqueId(FaceletCompositionContextImpl.java:910)
    at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.generateUniqueId(DefaultFaceletContext.java:321)
    at org.apache.myfaces.view.facelets.compiler.UIInstructionHandler.apply(UIInstructionHandler.java:87)
    at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:49)
    at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:158)
    at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57)
    at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
    at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:394)
    at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:448)
    at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:426)
    at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:244)
    at com.example.Include.encodeChildren(Include.java:54)

MyFaces basically releases the Facelet context during end of view build time, making it unavailable during view render time, resulting in NPEs because the internal state has several nulled-out properties. It's however possible to add individual components instead of a Facelet file during render time. I didn't really have had the time to investigate if this is my fault or MyFaces' fault. That's also why it didn't end up in OmniFaces yet.

If you're using Mojarra anyway, feel free to use it. I however strongly recommend to test it thoroughly with all possible use cases on the very same page. Mojarra has some state saving related quirks which might fail when using this construct.

Community
  • 1
  • 1
BalusC
  • 992,635
  • 352
  • 3,478
  • 3,452
  • I have some trouble to include the facelet. Is it sufficient to just `getChildren().clear()`? I get lots and lots of duplicate Id's. All the components, that were included in the previous request are stored in the `StateContext`. I kinda solved the issue, by just removing those from `dynamicComponents` and `dynamicActions`. But I am afraid I will get additional problems, won't I? – Bruno Schäpper Dec 05 '12 at 18:02
  • How is your state saving configured? Is all set to default? I'd love to see a minimum view/bean example which reproduces this problem. I've tested this only with a very simple `` in each include (also with `` and action method). – BalusC Dec 05 '12 at 18:08
  • `PARTIAL_STATE_SAVING` is enabled, `STATE_SAVING_METHOD` is set to server. A simple example is probably impossible, I am creating some components dynamically inside the included facelet, include other facelets in the included facelet and so on.. Yes, crazy ;-) I'll try to sort it out. What about the `getChildren().clear()`? Should it be sufficient? – Bruno Schäpper Dec 06 '12 at 06:57
  • I tried your approach, but unfortunately I have the same Problem as in my PhaseListener experiment. Duplicate ID's. I managed to get most of them out, by fumbling around in StateContext#dynamicActions, but that feels more than dirty and doesn't work for `ui:repeat` Have you tried this one yet? http://stackoverflow.com/a/5755972/1551204 It seems to work well. – Bruno Schäpper Dec 06 '12 at 13:32
  • Do you see chance to post the smallest possible code snippet which reproduces the duplicate ID problem? – BalusC Dec 06 '12 at 13:33
  • What would be an alternative approach, with similar flexibility? – Bruno Schäpper Dec 07 '12 at 11:49
  • So far I see none. I will however investigate this weekend. This is not an uncommon requirement. – BalusC Dec 07 '12 at 12:04
  • The duplicate ID Problem seems to be a Mojarra 2.1.15 bug, completely unrelated to include. I'll put something together and report it. Thanks for your help! – Bruno Schäpper Dec 11 '12 at 06:51
  • Thanks again for your help, there is now a bug reported: http://java.net/jira/browse/JAVASERVERFACES-2636 Your approach works, apart from that. – Bruno Schäpper Jan 08 '13 at 08:44