2010-03-26 20 views
0
<h:dataTable cellpadding="0" cellspacing="0" 
    styleClass="list_table" id="OuterItems" 
    value="#{valueList.values}" var="item" border="0"> 
    <h:column rendered="#{item.typeA}"> 
     <h:dataTable cellpadding="0" cellspacing="0" 
     styleClass="list_table" id="InnerItems" 
     value="#{item.options}" var="option" border="0"> 
      <h:column > 
       <h:outputText value="Option: #{option.displayValue}"/> 
      </h:column> 
     </h:dataTable> 
    </h:column> 
    <h:column rendered="#{item.typeB}"> 
     <h:dataTable cellpadding="0" cellspacing="0" 
     styleClass="list_table" id="InnerItems" 
     value="#{item.demands}" var="demand" border="0"> 
      <h:column > 
       <h:outputText value="Demand: #{demand.displayValue}"/> 
      </h:column> 
     </h:dataTable> 
    </h:column> 
</h:dataTable> 

public class Item{ 
    ... 
    public boolean isTypeA(){ 
     return this instanceof TypeA; 
    } 

    public boolean isTypeB(){ 
     return this instanceof TypeB; 
    } 
    ... 

} 

public class typeA extends Item(){ 
    ... 
    public List getOptions(){ 
     .... 
    } 
    ... 
} 

public class typeB extends Item(){ 
    ... 
    public List getDemands(){ 
     ... 
    } 
    .... 
} 

Je rencontre un problème avec JSF. J'ai résumé le problème ici, et j'espère que quelqu'un pourra m'aider à comprendre comment ce que je fais échoue. Je suis en boucle sur une liste d'éléments. Ces éléments sont en fait des instances des sous-classes TypeA et TypeB. Pour le type A, je veux afficher les options, pour le type B, je veux afficher les demandes. Lors du rendu de la page pour la première fois, cela fonctionne très bien. Cependant, quand je posterai revenir à la page pour une action, je reçois une erreur:JSF interne datable ne respectant pas la condition rendue de la table externe

[3/26/10 12:52:32:781 EST] 0000008c SystemErr  R javax.faces.FacesException: Error getting property 'options' from bean of type TypeB 
    at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:89) 
    at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java(Compiled Code)) 
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:91) 
    at com.ibm.faces.portlet.FacesPortlet.processAction(FacesPortlet.java:193) 

Mon emprise sur le Lifecyle JSF est très rude. À ce stade, je comprends qu'il y a une erreur dans les Phases ApplyRequestValues ​​qui est très précoce et donc l'état précédent est restauré et rien ne change. Ce que je ne comprends pas, c'est que pour remplir la condition de rendu "item.typeA" cet objet doit être une instance de TypeA. Mais ici, il semble que cet objet a passé la condition même s'il s'agissait d'une instance de TypeB. C'est comme s'il évaluait le dataTable interne (InnerItems) avant d'évaluer le externe (outerItems). Mon hypothèse de travail est que je ne comprends pas comment/quand l'attribut rendu est réellement évalué.

Répondre

2
<h:column rendered="#{item.typeA}"> 
     <h:dataTable cellpadding="0" cellspacing="0" 
     styleClass="list_table" id="InnerItems" 
     value="#{item.options}" var="option" border="0" 
     rendered="#{item.typeA}"> <!-- THIS IS THE CHANGE --> 
      <h:column > 
       <h:outputText value="Option: #{option.displayValue}"/> 
      </h:column> 
     </h:dataTable> 
    </h:column> 

D'une certaine façon d'ajouter la condition rendu directement au datatable ne se produit pas à moi dans mes nombreuses heures itération de suppositions/chasse aux œufs (j'étais vraiment désespérée). Je ne comprends toujours pas pourquoi cela n'a pas fonctionné en premier lieu, mais ça marche.

0

Je sais que c'est un ancien poste mais ... si vous vous demandez encore pourquoi il ne fonctionnait pas dans votre premier extrait, il est probablement parce que vous manque l'accolade fermante:

<h:column rendered="#{item.typeA"> 
<h:column rendered="#{item.typeB"> 

Cette a été correctement défini lorsque vous avez placé la condition rendue sur le datatable.

rendered="#{item.typeA}"> <!-- THIS IS THE CHANGE --> 
+1

C'était juste une faute de frappe de l'OP. Si cela était réel, OP aurait immédiatement fait face à l'exception lors de la visualisation de la page, pas lors de la soumission de la page. – BalusC