Hi,
When a table contains editable components, the "value" list is fetched
at the following times:
(initial page view occurs)
* during the rendering phase
(postback occurs)
* during validation phase
(navigate occurs, ie internal forward)
* during the rendering phase
....
The data is needed at the validation phase in order to determine whether
ValueChangeEvent events should be queued. The same list is retained by
the UIData and used during the update-model phase when the validated
values are pushed to the backing objects from the value list. A new list
must be fetched before rendering, however, as the list may change as a
result of processing during update-model or invoke-application phases.
When a table contains editable components, the table fetched during the
validation phase must contain exactly the same elements (and in exactly
the same order) as was present during the previous rendering phase. If
this isn't true then all sorts of confusion can occur.
Are your checkbox components bound to some backing list whose size has
changed? I can't see why that would happen, but it would explain some of
your symptoms. The table is iterating through all its rows, fetching the
corresponding element from the value list for that row, and then trying
to determine whether the submitted value is different from the value of
the corresponding model object. If the list is too short, then of course
an exception will occur while trying to fetch the matching model object.
Regards,
Simon
Matthias Kahlau wrote:
Hi!
Ok, it seems that the rendering behavior of the selectBooleanCheckbox (with
immediate = false) inside a dataTable is how to expect from an
EditableValueHolder, and I have to call either setSubmittedValue(null) or
setSelectedState(false) to prevent the checkboxes from beeing selected if
the page is redisplayed, dependent on the immediate state of the
commandButton:
- setSubmittedValue(null) if commandButton is immediate = true -> submitted
value is rendered if not null
- setSelectedState(false) if commandButton is immediate = false
But what I don't really understand is, why the problem described (all
checkboxes are selected when the page is redisplayed, and runtime error
after deleting this selection) only happens when the checkbox of the last
shown row has been selected, and not when any other checkbox had been
selected. Any ideas?
Regards,
Matthias
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Auftrag
von Matthias Kahlau
Gesendet: Dienstag, 6. Dezember 2005 02:47
An: Users MyFaces
Betreff: Problem with selectBooleanCheckbox inside dataTable
Hi!
I encounter a strange behavior of selectBooleanCheckbox component-binding
inside a dataTable. When I select the checkbox in the last row and call an
action method to delete the selected row, the page is redisplayed with all
the remaining checkboxes selected, that had been deselected before.
This happens only if I select the last row/checkbox, not if I
select another
row and press delete. I don't modify any component state in the
application.
This behavior is independent of setting the selectBooleanCheckbox or the
delete commandButton to false/true.
The behavior described doesn't happen in any possible case, but
always when
the options are shown the first time and I select the last one and press
delete.
If this happens, and the checkboxes are all redisplayed in selected state,
and I press delete, a runtime error is thrown because a "row is
unavailable":
02:36:22,218 ERROR [Engine] StandardWrapperValve[Faces Servlet]:
Servlet.service() for servlet Faces Servlet threw exception
javax.faces.FacesException: Error calling action method of
component with id
_id1:_id34
at
org.apache.myfaces.application.ActionListenerImpl.processAction(Ac
tionListen
erImpl.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90)
at
javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:132)
at
org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(Life
cycleImpl.
java:219)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:71)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:106)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
pplication
FilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
onFilterCh
ain.java:157)
at
org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(E
xtensionsF
ilter.java:123)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
pplication
FilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
onFilterCh
ain.java:157)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeade
rFilter.ja
va:75)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A
pplication
FilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati
onFilterCh
ain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
erValve.ja
va:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(Stand
ardContext
Valve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardConte
xtValve.ja
va:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:104)
at
org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPr
incipalVal
ve.java:66)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:102)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Secu
rityAssoci
ationValve.java:150)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:102)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextV
alve.java:
54)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv
e.java:137
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValv
e.java:118
)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine
Valve.java
:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardV
alveContex
t.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.
java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.pr
ocessConne
ction(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thre
adPool.jav
a:683)
at java.lang.Thread.run(Thread.java:534)
Caused by: javax.faces.el.EvaluationException: Exception while invoking
expression #{ChooseAuswBerechtigteBacking.removeAuswBerechtigte}
at
org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:153)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(Ac
tionListen
erImpl.java:63)
... 42 more
Caused by: java.lang.IllegalArgumentException: row is unavailable
at
javax.faces.model.ListDataModel.getRowData(ListDataModel.java:61)
at
org.apache.myfaces.component.html.ext.HtmlDataTableHack.getRowData
(HtmlDataT
ableHack.java:88)
at
de.fhzw.portal.umfragesystem.view.backing.management.ChooseAuswBer
echtigteBa
cking.getSelectedAuswBerechtigte(ChooseAuswBerechtigt
eBacking.java:502)
at
de.fhzw.portal.umfragesystem.view.backing.management.ChooseAuswBer
echtigteBa
cking.removeAuswBerechtigte(ChooseAuswBerechtigteBack
ing.java:261)
at sun.reflect.GeneratedMethodAccessor2984.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
cessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:129)
... 43 more
I can solve the problem by setting the submitted value of the checkbox
component-binding to null at the end of the delete action method, but I
think it looks like a hack. Setting the checkbox
component-binding selected
state to false has no effect.
Can somebody explain the behavior, and maybe provide a cleaner solution?
Regards,
Matthias
