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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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.RequestContextImpl
addPartialTriggerListeners
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
