myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafa PĂ©rez" <raja...@gmail.com>
Subject Re: [Trinidad] PPR and inputDate problems
Date Mon, 11 Feb 2008 10:06:32 GMT
Could you change your h:dataTable for a tr:table?? Just to see what
happens...

On Feb 11, 2008 8:30 AM, Shane Petroff <shane@mayet.ca> wrote:

>  Andrew Robinson wrote:
>
> Subform is a naming container, so you will have to give it an ID and use
> colons to get out and back in.
>
>
> OK, when I tried, I didn't explicitly name the subforms, I just used 4
> colons. Unfortunately, the subforms (named or not) made things worse. When
> the subforms were introduced, the value change listener is never called.
>
>
> Replace the inputDate with an outputText of the same ID -- does it update?
> - If so this is not a PPR problem
>
>
> It does not update; this was my original setup. It is not PPR per se,
> because I slapped a couple of arbitrary text boxes on the form and was able
> to get them linked very easily, the issue seems to be PPR within the
> dataTable.
>
>
> Leave it as an inputDate and use the Firebug extension in Firefox to view
> the AJAX response. Does it contain the inputDate?
>
>
> I've never really used Firebug before, so forgive me if I've got it wrong,
> but in Inspect/Console, there appears to be POST entries corresponding to
> the AJAX calls (Common1_0_5.js line 10680 to be specific). The POST tab
> indicates what looks to be correct data:
>
>   _idJsp1:_idJsp4:6:finalMarkField 44  _idJsp1:_idJsp4:6:withdrawalDate
>   _idJsp1:_idJsp4:7:finalMarkField
>   _idJsp1:_idJsp4:7:withdrawalDate
>   _idJsp1:_idJsp4:8:finalMarkField
>   _idJsp1:_idJsp4:8:withdrawalDate
>   _idJsp1:_idJsp4:9:finalMarkField
>   _idJsp1:_idJsp4:9:withdrawalDate
>   _idJsp1:xxx
>   _idJsp1:yyy
>   event autosub  org.apache.myfaces.trinidad.faces.FORM _idJsp1
> org.apache.myfaces.trinidad.faces.STATE !5e7200c0  partial true  source
> _idJsp1:_idJsp4:6:finalMarkField
> but the response tab make no mention of the date field.
>
> <?xml version="1.0" ?>
> <?Tr-XHR-Response-Type ?>
> <content action="/reportCard/pages/classList.jsf">
> <body class="page-background">
>
> <!-- MYFACES JAVASCRIPT -->
> </body>
> <fragment><![CDATA[<span id="tr__idJsp1_Postscript"><input type="hidden"
> name="org.apache.myfaces.trinidad
> .faces.STATE" value="!5e7200c0"><input type="hidden"
> name="source"></span>]]></fragment>
> <script><![CDATA[TrPage.getInstance
> ()._addResetFields('_idJsp1',["source"]);]]></script><script><![CDATA
> [var _idJsp1_SF={};]]></script></content>
>
>
> If the above shows that it is not a PPR problem and you don't want to
> bother with the subform, put a breakpoint in your set method to see who is
> calling it and with what value. The stack trace should show you the caller
> and you can determine the phase.
>
>
> This I'd done previously, but wasn't able to decipher the results. If I
> manufacture an exception, then fill in and print it's stack trace, I get the
> following:
>
> WARNING: Could not find partial trigger :::finalMarkField from
> CoreInputText[UIXEditableFacesBeanImpl, id=withdrawalDate]
> (The warning is generated prior to manufacturing the exception below. This
> scenario is with no subforms)
>
> java.lang.Exception
>     at ca.mayet.backing.ClassListBean.finalMarkChanged(ClassListBean.java
> :188)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.apache.myfaces.el.MethodBindingImpl.invoke(
> MethodBindingImpl.java:132)
>     at
> org.apache.myfaces.trinidad.component.UIXComponentBase.broadcastToMethodBinding
> (UIXComponentBase.java:1188)
>     at org.apache.myfaces.trinidad.component.UIXEditableValue.broadcast(
> UIXEditableValue.java:213)
>     at javax.faces.component.UIData.broadcast(UIData.java:517)
>     at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java
> :97)
>     at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java
> :150)
>     at org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(
> ProcessValidationsExecutor.java:32)
>     at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
> LifecycleImpl.java:95)
>     at org.apache.myfaces.lifecycle.LifecycleImpl.execute(
> LifecycleImpl.java:70)
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:269)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:188)
>     at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(
> ExtensionsFilter.java:144)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:215)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:188)
>     at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter
> (TrinidadFilterImpl.java:253)
>     at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl
> (TrinidadFilterImpl.java:210)
>     at
> org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(
> TrinidadFilterImpl.java:164)
>     at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(
> TrinidadFilter.java:92)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:215)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:188)
>     at
> org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal
> (OpenSessionInViewFilter.java:173)
>     at org.springframework.web.filter.OncePerRequestFilter.doFilter(
> OncePerRequestFilter.java:77)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:215)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:188)
>     at ca.mayet.SessionTimeoutRedirectFilter.doFilter(
> SessionTimeoutRedirectFilter.java:78)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:215)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:188)
>     at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:210)
>     at org.apache.catalina.core.StandardContextValve.invoke(
> StandardContextValve.java:174)
>     at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:127)
>     at org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:117)
>     at org.apache.catalina.core.StandardEngineValve.invoke(
> StandardEngineValve.java:108)
>     at org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:151)
>     at org.apache.coyote.http11.Http11Processor.process(
> Http11Processor.java:870)
>     at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
> (Http11BaseProtocol.java:665)
>     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> PoolTcpEndpoint.java:528)
>     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> LeaderFollowerWorkerThread.java:81)
>     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:685)
>     at java.lang.Thread.run(Thread.java:619)
>
> How can I tell from this information which phase is being executed? I'm
> assuming that the processValidators call buried in there tells me that it is
> happening early (before model updates), but the info didn't mean much to me.
> FWIW, there are no validators attached, unless there is something embedded
> in the component itself.
>
> otherwise, try this:
>
>
> except for the names, this is what I'd tried previously. Unfortunately,
> naming the subforms did not help.
>
> In any case, thanks for all of your help Andrew.
>
> Shane
>
>
>
> <h:dataTable ...
>   <h:column>
>     <f:facet
>       name="header">
>       <h:outputText
>         value="#{bundle.ClassListFinalMarkHeader}"
>         styleClass="label"/>
>     </f:facet>
>     <tr:subform id="finalMarkForm">
>       <tr:inputText
>         id="finalMarkField"
>         columns="5"
>         value="#{studentSec.finalMark}"
>         autoSubmit="true"
>         valueChangeListener="#{classListBean.finalMarkChanged}"/>
>     </tr:subform>
>   </h:column>
>   <h:column>
>     <f:facet
>       name="header">
>       <h:outputText
>         value="#{bundle.ClassListWithdrawalDateHeader}"
>         styleClass="label"/>
>     </f:facet>
>     <tr:subform id="withdrawalDateForm">
>       <tr:inputDate
>         id="withdrawalDate"
>         columns="11"
>         partialTriggers=":::finalMarkForm:finalMarkField"
>         value="#{studentSec.withdrawalDate}"
>         required="false"/>
>       <h:message for="withdrawalDate"/>
>     </tr:subform>
>   </h:column>
>
> Note that in trinidad 1.x.7 this will become
> partialTriggers="::finalMarkForm:finalMarkField" (one less colon).
>
>
>
> On Feb 8, 2008 4:26 PM, Shane Petroff <shane@mayet.ca> wrote:
>
> >  Andrew Robinson wrote:
> >
> > I think I know your problem. It is a phase issue
> >
> >
> > I'll take your word for it, but I guess the only thing I could do to try
> > and trace it through was to set a breakpoint in the decode method and step
> > through everything.
> >
> > and why value change listeners (VCL) suck in JSF (really bad
> > architecture)
> >
> >
> > Is there a better option? Even combos fire value changes.
> >
> >
> > The VCL architecture sucks as it is not transaction aware, and the
> > events fired in the validation doesn't mean that the update will ever be
> > done (so the new value may never become the actual value). Also, when the
> > VCL is invoked, the model is not updated, so you can't trust values from the
> > model layer (beans) since they may have pending changes.
> >
> > I haven't tried it, but add a <tr:subform> around each input. This
> > should only validate & update the value that has changed instead of the
> > entire form.
> >
> >  Didn't work. I'm using
> >
> >   <h:column>
> >         <tr:subform>
> >             <tr:inputText
> >
> > and similar for the inputDate
> >
> > One curious thing about this layout is that it can no longer find
> > partial triggers fields when a normal name is specified for partialTriggers.
> >
> > Feb 8, 2008 5:12:16 PM
> > org.apache.myfaces.trinidadinternal.context.RequestContextImpladdPartialTriggerListeners
> > WARNING: Could not find partial trigger finalMarkField from
> > CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp14]
> >
> > I tried the preceding colons as well (4 of them this time because of the
> > additional nesting), but no luck there either.
> >
> > Surely I'm not the first person to try to use PPR/ValueChange on an
> > editable table am I?
> >
> >
> > On Feb 8, 2008 1:14 PM, Shane Petroff <shane@mayet.ca> wrote:
> >
> > >  Andrew Robinson wrote:
> > >
> > >
> > > What trinidad build are you using?
> > >
> > >
> > > Trinidad 1.0.5,
> > > MyFaces Core 1.1.5
> > >
> > >
> > > colons should not be necessary for components in the same naming
> > > container.
> > >
> > >
> > > Tried with and without. Using the colons clearly does not work because
> > > it issues the warning:
> > >
> > > WARNING: Could not find partial trigger :::finalMarkField from
> > > CoreInputDate[UIXEditableFacesBeanImpl, id=_idJsp12]
> > >
> > > With no preceding colons there is no warning generated, but the field
> > > is never refreshed either. The value change method is below, as is a
> > > stripped down jsp. I can see the value change being fired, but where would
I
> > > even set a breakpoint to tell if anything is happening on the
> > > partialTriggers side?
> > >
> > >
> > >
> > >     public void finalMarkChanged( ValueChangeEvent event )
> > >     {
> > >         StudentSection ss = (StudentSection) m_Table.getRowData();
> > >          ss.setWithdrawalDate(new Date()); // I'm assuming that this
> > > instance is still around to refresh the field from
> > >         System.out.println( "finalMarkChanged for " +
> > > ss.getStudentName() + " " + ss.getWithdrawalDate() );
> > >     }
> > >
> > >
> > >  <f:view>
> > >
> > > <tr:document title="#{bundle.ClassListHeader}">
> > >
> > > <body class="page-background">
> > >
> > > <h:form>
> > >
> > >   <h:panelGrid headerClass="page-header" styleClass="panel"
> > >                columns="1" cellpadding="5">
> > >
> > >     <h:messages showDetail="true" showSummary="false"
> > > styleClass="errors"/>
> > >
> > >     <h:dataTable styleClass="dataTable"
> > >                  rowClasses="list-row-even,list-row-odd"
> > > cellpadding="4" border="0"
> > >                  headerClass="list-header"
> > >                  cellspacing="0"
> > >                  value="#{classListBean.studentSections}"
> > >                  var="studentSec"
> > >                  binding="#{classListBean.table}">
> > >
> > >       <h:column>
> > >         <f:facet name="header">
> > >           <h:commandLink styleClass="table-header" id="studentDesc"
> > >                          actionListener="#{classListBean.sort}">
> > >             <h:outputText value="#{bundle.StudentColHeader}"/>
> > >           </h:commandLink>
> > >         </f:facet>
> > >         <h:outputText value="#{studentSec.studentName}"/>
> > >       </h:column>
> > >
> > >       <h:column>
> > >         <f:facet name="header">
> > >              <h:outputText value="#{bundle.ClassListFinalMarkHeader}"
> > > styleClass="label"/>
> > >         </f:facet>
> > >         <tr:inputText id="finalMarkField"
> > >                       columns="5"
> > >                       value="#{studentSec.finalMark}"
> > >                       autoSubmit="true"
> > >                       valueChangeListener="#{
> > > classListBean.finalMarkChanged}"/>
> > >       </h:column>
> > >
> > >       <h:column>
> > >         <f:facet name="header">
> > >             <h:outputText value="#{
> > > bundle.ClassListWithdrawalDateHeader}" styleClass="label"/>
> > >         </f:facet>
> > >          <tr:inputDate columns="11"
> > >                       partialTriggers=":::finalMarkField"
> > >                       value="#{studentSec.withdrawalDate}"
> > >                       required="false" >
> > >              <f:convertDateTime pattern="dd-MMM-yyyy" timeZone="#{
> > > configBundle.TimeZone}"/>
> > >         </tr:inputDate>
> > >       </h:column>
> > >
> > >     </h:dataTable>
> > >
> > >   </h:panelGrid>
> > >
> > > </h:form>
> > >
> > > </body>
> > >
> > >  </tr:document>
> > >
> > > </f:view>
> > >
> > >
> > >
> > > On Feb 8, 2008 10:31 AM, Shane Petroff <shane@mayet.ca> wrote:
> > >
> > > > Matthias Wessendorf wrote:
> > > > > ah,
> > > > > I just noticed, that "finalMarkField" is inside a table (naming
> > > > container).
> > > > > haven't read your code carefully, sorry.
> > > > >
> > > > > can you *try* partialTriggers=":::finalMarkField" ?
> > > > >
> > > >
> > > >  No joy... cleared the browser cache first, then dumped tomcat's
> > > > cache,
> > > > did a full build and restarted the server. I also tried :: and ::::
> > > > variants (3 does appear to be the correct number though based on the
> > > > generated html), but still no partial triggers refresh. Would it be
> > > > more
> > > > likely to work if I switched to a tr:table?
> > > >
> > > > --
> > > > Shane
> > > >
> > > >
> > >  --
> > > Shane
> > >
> > >
> >
> >
> >  --
> > Shane
> >
> >
>
>
> --
> Shane
>
>

Mime
View raw message