2 Replies Latest reply on Mar 16, 2009 2:46 PM by Guillaume Jeudy

    listShuttle validation quirk ?

    Guillaume Jeudy Master

      Hi,

      I'm using Richfaces 3.2.1.GA here is my usecase I have a listShuttle that displays data and I hooked a custom JSF validator on a hidden field that is invoked for every row.

      Example simplified for demonstration purposes:

      <a4j:form id="toRelShuttleForm">
       <rich:listShuttle id="toRelShuttle"
       targetValue="#{relatedToInstances}"
       sourceValue="#{unrelatedToInstances}" converter="#{a.b.c.converter.IdentifiableConverter}" var="domInstVO">
      
       <h:column> <f:facet name="header"> <h:outputText value="Id" /> </f:facet> <h:outputText value="#{domInstVO.idForJsf}"/>
       <h:inputHidden value="#{domInstVO.idForJsf}">
       <f:attribute name="formId" value="toRelShuttleForm:toRelShuttle" />
       <f:attribute name="formFieldNames" value="validFromDate,validToDate" />
       <f:attribute name="backingBeanName" value="validityPeriod" />
       <f:validator validatorId="validityPeriodValidator"/>
       </h:inputHidden>
       </h:column>
       <h:column>
       <f:facet name="header">
       <h:outputText value="Valid From Dt" />
       </f:facet>
       <h:inputText id="validFromDate"
       value="#{domInstVO.validityPeriod.validFromDate}" />
       </h:column>
       <h:column>
       <f:facet name="header">
       <h:outputText value="Valid To Dt" />
       </f:facet>
       <h:inputText id="validToDate"
       value="#{domInstVO.validityPeriod.validToDate}" />
       </h:column>
       <!-- snip snip -->
      </rich:listShuttle>
      <h:commandButton type="submit" action="#{domRelateInstancesAction.confirm}" value="Save" rendered="#{editMode}" />
      <s:button action="#{conversation.endAndRedirect}" value="Cancel" rendered="#{editMode and conversation.nested}" />
      </a4j:form>


      If I move an item from source list to target list then change editable fields to an invalid combination on the row. I click the commandButton and validation fails.

      The page is rerendered on post-back but the faulty editable fields on the row do not contain the previously invalid submitted values. It contains the initial values, if I try to submit again validation fails again even though the user may believe it should pass because initial value is valid even though JSF UI Tree still contains previously invalid submitted values...

      This scenario works if I edit a value already in targetList.

      Please advise, this seems like a listShuttle specific quirk.

      Thanks,
      -Guillaume

        • 1. Re: listShuttle validation quirk ?
          Ilya Shaikovsky Master

          1) try to simplify your sample from the beggining. For example remove the validated hiddens column. Maybe the problems started with converter. And there is nothing about validation?
          2) Please check with 3.3.0 additionally. There where issue with convertation in previous versions and there are fixed in current release.

          • 2. Re: listShuttle validation quirk ?
            Guillaume Jeudy Master

            1) I simplified the example dramatically for your benefit but I still have the same problem.

            <rich:listShuttle
             targetValue="#{targetValue}"
             sourceValue="#{sourceValue}"
             converter="#{a.b.c.converter.IdentifiableConverter}"
             var="refDomain">
             <h:column>
             <f:facet name="header">
             <h:outputText value="Description" />
             </f:facet>
             <h:inputText value="#{refDomain.domainDescription}">
             <f:validateLength maximum="40"/>
             </h:inputText>
             </h:column>
             </rich:listShuttle>


            2. Using 3.3.0.GA still exhibits the same problem.

            One important point I had to keep the custom converter otherwise I don't see any way of having a list of objects (not simple types) as the backing beans of the shuttle. I know the converter works fine in both 3.2.1.GA and 3.3.0.GA because I'm able to do simple CRUD operations (without the validation).