4

I have a page using dynamic forms where I am creating the component tree programatically (which is not up for debate in this question) Some of the input controls I need to render require an ajax handler.

The xhtml fragment (included by a <ui:include> from another fragment) is :

<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" xmlns:p="http://xmlns.jcp.org/jsf/passthrough">

    <h:panelGroup id="id_Group1" binding="#{questionaire.group1}" layout="block"/>

</ui:composition>

Based on other SO anwsers, I have the following bean code:

   public HtmlPanelGroup getGroup1() {

        // irrelevant code omitted

        HtmlSelectOneRadio selectUI = new HtmlSelectOneRadio();
        AjaxBehavior valueChangeAction = (AjaxBehavior)FacesUtils.getApplication().createBehavior(AjaxBehavior.BEHAVIOR_ID);

        valueChangeAction.addAjaxBehaviorListener(new ProbeQuestionListener(currentQuestion, "probeDiv" + questionNumber));


        selectUI.addClientBehavior("change", valueChangeAction);
        valueChangeAction.setRender(Collections.singletonList("probeDiv" + questionNumber));

       // further code to customise the control, create the panel group and probe div and wire everything together omitted
    }

This renders correctly and I see:

<input type="radio" onchange="mojarra.ab(this,event,'change',0,'probeDiv2')" value="0" id="answer_1:0" name="answer_1">

However, clicking the radio button gives me a javascript console error: reference error: mojarra is not defined

Now, if I modify the xhtml to include a "normal" ajax control, e.g.

<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" xmlns:p="http://xmlns.jcp.org/jsf/passthrough">

    <h:panelGroup id="id_Group1" binding="#{questionaire.group1}" layout="block"/>

    <!-- include a hacky hidden ajax field to force inclusion of the ajax javascript -->
    <h:panelGroup layout="block" id="hiddenAjaxDiv" style="display:none">
        <h:inputText id="hiddenAjax">
            <f:ajax execute="hiddenAjax" render="hiddenAjaxDiv" />
        </h:inputText>
    </h:panelGroup>    

</ui:composition>

This works and firebug network monitor shows my ajax event from the radio button is posted to the app.

So, finally, my question:

How do I programatically force the inclusion of the ajax javascript library and dispense with the horrible hack I am currently using?

Note: I am not interested in any answer that starts "don't use dynamically generated components" - for several reasons, this is not an option.

Steve Atkinson
  • 1,197
  • 2
  • 10
  • 27

1 Answers1

9

Basically, you need this:

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

That script contains the mojarra definition among the standard jsf namespace containing the JSF ajax scripts.

You can explicitly declare it in the <h:head> of your master template, if necessary via <ui:define>/<ui:include>. It won't load duplicate copies of the jsf.js file if already implicitly required by the view.

You can even programmatically create it:

UIComponent jsfjs = new UIOutput();
jsfjs.getAttributes().put("library", "javax.faces");
jsfjs.getAttributes().put("name", "jsf.js");
jsfjs.setRendererType("javax.faces.resource.Script");
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().addComponentResource(context, jsfjs, "head");

Also here, it won't load duplicate copies of the jsf.js file if already implicitly required by the view.


Unrelated to the concrete problem, you should prefer <f:event type="postAddToView"> over binding when you need to programmatically populate the component tree:

<h:panelGroup id="id_Group1" layout="block">
    <f:event type="postAddToView" listener="#{questionaire.populateGroup1}" />
</h:panelGroup>

with

public void populateGroup1(ComponentSystemEvent event) {
    HtmlPanelGorup group1 = (HtmlPanelGroup) event.getComponent();
    // ...
}

This guarantees that the tree is populated at exactly the right moment, and keeps getters free of business logic, and avoids potential "duplicate component ID" trouble when #{questionaire} is in a broader scope than the request scope, and keeps the bean free of UIComponent properties which in turn avoids potential serialization trouble and memory leaking when the component is held as a property of a serializable bean.

BalusC
  • 1,040,783
  • 362
  • 3,548
  • 3,513
  • Marvellous! Once again, you've solved our problem. I will also look into the postAddToView as you suggest. – Steve Atkinson Nov 13 '13 at 17:55
  • balus, can you please expand on duplicate Id issues if my bean is in view scope? I vaguely remember reading this somewhere a while ago but can't find the question in which you discussed the detail of it – Steve Atkinson Nov 13 '13 at 20:35
  • 1
    @SteveAtkinson I guess it's too late to reply you, but here is the detailled explanation if someone else ended here: http://stackoverflow.com/a/14917453/4170582 – Tarik Mar 11 '15 at 10:47
  • Thanks for the prompt - I'd actually forgotten to look into it - and the reminder is timely as I shortly need to amend that bean for some new features. The article explains some behaviour I saw when first writing the class that I didn't fully understand and to get around it, I shamefully was programatically recreating the view on each request - now I know why that was happening and can change t the correct method that Balus suggests, – Steve Atkinson Mar 14 '15 at 12:29