Comment soumettre un formulaire lorsque son rendu est basé sur une valeur dans un haricot de requête

Question

J'ai découvert un problème dans mon petit programme et je me demande si quelqu'un a des astuces ou des conseils pour résoudre ce problème le mieux possible.

J'ai le bean testBean qui est dans la portée de la demande. Il contient les éléments suivants:

public class testBean {

private boolean internal = false; 
private String input = "";

public String internalTrue() {
    System.out.println("Set internal true");
    setInternal(true);
    return null;
}
public String submitForm() {
    System.out.println("");
    return null;
}
public boolean isInternal() {
    return internal;
}
public void setInternal(boolean internal) {
    this.internal = internal;
}
public String getInput() {
    return input;
}
public void setInput(String input) {
    this.input = input;
}

}

Mon fichier welcomeJSF.jsp contient ceci:

    <f:view>
        <h:form>
            <h:commandButton value="Set internal true" action="#{testBean.internalTrue}" />
        </h:form>
        <h:panelGrid columns="1" rendered="#{testBean.internal}">
            <h:form>
                <h:outputText value="JavaServer Faces" /><h:inputText value="#{testBean.input}" />
                <h:commandButton value="Go" action="#{testBean.submitForm}" />
            </h:form>
        </h:panelGrid>
    </f:view>

Lorsque j'exécute l'application, le bouton "Set internal true" lui est présenté. Je clique dessus et je me présente avec le formulaire où j'ai le bouton "Go". En cliquant sur & Go; Go " ne déclenche pas la méthode dans mon bean, probablement parce que le champ n'est plus rendu sur le serveur, et donc il n'exécutera pas la méthode. Existe-t-il des solutions intelligentes à cet égard?

D'avance, merci de votre temps.

Answer 1

Les enfants du panneau ne décoderont jamais les entrées car son attribut rendu est toujours évalué à false au cours de la phase APPLY REQUEST VALUES. C’est une chose sensée à faire du point de vue de la sécurité.

_{(source: ibm.com )}

Vous pouvez notamment tirer parti du fait que les composants JSF conservent l'état pendant toute la durée de la vue.

Le nouveau haricot:

public class TestBean {

  private String input = null;
  private UIComponent panel;

  public String internalTrue() {
    panel.setRendered(true);
    return null;
  }

  public String submitForm() {
    panel.setRendered(false);
    System.out.println("submitForm");
    return null;
  }

  public UIComponent getPanel() { return panel; }
  public void setPanel(UIComponent panel) { this.panel = panel; }

  public String getInput() { return input; }
  public void setInput(String input) { this.input = input; }

}

La nouvelle vue liée au bean:

  <f:view>
    <h:form>
      <h:commandButton value="Set internal true"
        action="#{testBean.internalTrue}" />
    </h:form>
    <h:panelGrid binding="#{testBean.panel}" columns="1"
      rendered="false">
      <h:form>
        <h:outputText value="JavaServer Faces" />
        <h:inputText value="#{testBean.input}" />
        <h:commandButton value="Go" action="#{testBean.submitForm}" />
      </h:form>
    </h:panelGrid>
  </f:view>

Utilisation de l'attribut binding sur panelGrid provoquera l'appel de setPanel lors de la création / restauration de la vue.

Notez que vous pouvez avoir des tests à effectuer en fonction de la manière dont votre implémentation et / ou vos bibliothèques StateManager stocke les vues entre les demandes (qui peuvent à leur tour être affectées par le paramètre init javax.faces.STATE_SAVING_METHOD ). La vue peut être stockée dans un champ caché du formulaire, dans la session associée à l'ID de la vue (pouvant entraîner des conflits avec plusieurs fenêtres du navigateur), dans la session associée à un ID unique créé par une navigation GET ou JSF, ou par un mécanisme complètement personnalisé. La nature enfichable du framework le rend polyvalent, mais dans ce cas, cela signifie que vous devez revérifier le comportement de votre implémentation.