Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Matthias Kahlau" <mkahlau@web.de>
To: "MyFaces Discussion" <users@myfaces.apache.org>
Subject: AW: AW: Problem with selectBooleanCheckbox inside dataTable
Date: Wed, 7 Dec 2005 15:29:44 +0100
Message-ID: <GOEBIKNIPDKPOODCEIHHKEJMCFAA.mkahlau@web.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
In-Reply-To: <43960E46.1010203@obsidium.com>
Importance: Normal
Sender: mkahlau@web.de

Hi Simon,


thanks for your response. I use one UISelectBoolean component property in my
Backing-Bean, which is bound to the selectBooleanCheckbox used in the
dataTable. Because the dataTable has more than one row, that component or at
least the reference must be shared by all rows internally. Sharing seems to
be the source of the first problem, that all checkboxes are rendered as
selected when the page is redisplayed after a postback where only the last
checkbox was chosen.

It seems that the checkboxes are rerendered with the selected state of the
last checkbox processed (the checkbox of the last row), what can be
prevented by programmatically modifying the selected state of the
UISelectBoolean component in the postback.


And this solution also solved the second problem (runtime error), that
arised when I tried to delete all rows after the page had been redisplayed
with all checkboxes selected. The table used in the validation phase must
have become out of sync with the data rendered previously. But I can't
reproduce the error in the moment.


Regards,
Matthias

> -----Urspr�ngliche Nachricht-----
> Von: users-return-13346-mkahlau=web.de@myfaces.apache.org
> [mailto:users-return-13346-mkahlau=web.de@myfaces.apache.org]Im Auftrag
> von Simon Kitching
> Gesendet: Dienstag, 6. Dezember 2005 23:19
> An: MyFaces Discussion
> Betreff: Re: AW: Problem with selectBooleanCheckbox inside dataTable
>
>
> 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: users-return-13284-mkahlau=web.de@myfaces.apache.org
> >> [mailto:users-return-13284-mkahlau=web.de@myfaces.apache.org]Im 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
> >>
> >
> >
> >
>