1

I need your assistance in rendering inputText based on the selecttio of the selectManyCheckbox in the xhtml. The code is:

<p:selectManyCheckbox id="basic" value="#{user1.selectedConsoles}">
  <f:selectItem itemLabel="Xbox One SS" itemValue="XboxOne" />
  <f:selectItem itemLabel="PS4 SS" itemValue="PS4" />
  <f:selectItem itemLabel="Wii U SS" itemValue="WiiU" />
  <p:ajax listener="#{user1.renderInput}" update="name"/>
</p:selectManyCheckbox>

 <h:panelGroup id="name">
  <p:inputText value="" rendered="#{user1.renderText}"/>
 </h:panelGroup>

And the bean code:

private String[] selectedConsoles; //Setter & Getter
private List<String> list = new ArrayList<String>(); //Setter & Getter
private boolean renderText = false; //Setter & Getter


public void renderInput() {
  list= Arrays.asList(selectedConsoles);
  if (list.contains("PS4")) {
    renderText = true;
  }
  else if (!list.contains("PS4")) {
        renderText = false;
  }
}

In the above case, once I have selected PS4, the inputText will be shown. But when I unckeck PS4, the inputText will remain visible in the form and will not be 'unrendered'. How can I achieve this.

Kukeltje
  • 12,223
  • 4
  • 24
  • 47
99maas
  • 1,239
  • 12
  • 34
  • 59

1 Answers1

-1

For that there is the PrimeFaces OutputPanel component, which basically acts as placeholder. Either you use autoUpdate true, or you update it on select.

The following snippet solves your problem:

    <h:panelGroup id="name">
        <p:outputPanel autoUpdate="true">
            <p:inputText value="" rendered="#{user1.renderText}" />
        </p:outputPanel>
    </h:panelGroup>
Raphael H
  • 69
  • 6
  • I will remove the downvote once you edit your answer to explain how exactly OP's problem is caused and how exactly this approach solves it. Namely, OP's initial code should work just fine. – BalusC May 23 '15 at 20:12
  • @BalusC You are absolutely correct, your downvote is perfectly justified. Please post it as an actual answer, so I can remove mine. – Raphael H May 23 '15 at 21:01
  • You should probably improve the answer @RagnarT, rather than hastily deleting. Don't be so quick to back away. Your answer is not "wrong" as much as you haven't actually addressed the *why* of OP's problem. Hint: it's not in the markup – kolossus May 25 '15 at 08:00
  • @kolossus The problem is, that my suggested solution is a placebo in this case. It looks like it works, but actually it just bloats up the code, since the whole tag is not necessary. It's quite the contrary, if the OP uses it with autoUpdate="true" there will be unnecessary updates in every ajax-request. That is why I am convinced that my answer is more damaging than helpful. – Raphael H May 25 '15 at 08:22
  • My point @RagnarT , is that if you understand the flaw in your answer, fix it, rather than deleting it. The problem is not the markup, it's in the backing bean. – kolossus May 25 '15 at 08:45
  • @kolossus I tested the code in all scopes, the backing bean works fine as well. Where do you see an issue in it? – Raphael H May 25 '15 at 08:59
  • You can start with [this](http://stackoverflow.com/a/13716476/1530938) (which may not be all that's wrong with this question, OP hasn't given all the info) – kolossus May 25 '15 at 09:25
  • @kolossus the issue in your link doesn't affect the provided code here. You can toggle the checkboxes here as often as you want, you won't get a PropertyNotWritableException. If you use a commandButton, that is a different story. A p:commandButton will trigger once successfully, the second time the exception will get thrown, because the inputText is rendered. value="" works with either p:inputText or h:inputText in this case here. None the less, you are correct, that not enough information was supplied for a full analysis, but what is provided works fine. – Raphael H May 25 '15 at 09:46