Re: MyFaces binding problem with HtmlSelectOneMenu/SelectOneChoice

[Michael Kurz]

Yeah, this is the same I got. Should be fixed with the patch.

-
Michael


Am 26.01.2010 13:54, schrieb Mark Struberg:

Just in case it helps, I'm also having problems with HtmlSelectOne:
This used to work until last week.

Leonardos patch in MYFACES-2356.3 fixes this problem.

I'd say this is a blocker for the beta release...

LieGrue,
strub


2010-01-26 13:25:27.623:WARN::/reservation-fe/reservationRequest.jsf
java.lang.IllegalArgumentException: Expected submitted value of type String for 
component : {Component-Path : [Class: 
org.ajax4jsf.component.AjaxViewRoot,ViewId: /reservationRequest.xhtml][Class: 
javax.faces.component.html.HtmlForm,Id: suchformular][Class: 
org.richfaces.component.html.HtmlGraphValidator,Id: j_id9][Class: 
javax.faces.component.html.HtmlSelectOneRadio,Id: wellKnown]}
        at 
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:275)
        at 
org.apache.myfaces.shared_impl.renderkit.html.HtmlRadioRendererBase.encodeEnd(HtmlRadioRendererBase.java:97)
        at 
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:486)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:612)
        at 
org.richfaces.component.UIGraphValidator.encodeChildren(UIGraphValidator.java:268)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:603)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
        at 
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
        at 
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
        at 
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
        at 
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:107)
        at 
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
        at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
        at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
        at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
        at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
        at 
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
        at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
        at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)



--- On Tue, 1/26/10, Michael Kurz<michi.k...@gmx.at>  wrote:

From: Michael Kurz<michi.k...@gmx.at>
Subject: Re: MyFaces binding problem with HtmlSelectOneMenu/SelectOneChoice
To: users@myfaces.apache.org
Date: Tuesday, January 26, 2010, 10:22 AM
Hi Simon,

as you already have noticed, a component binding is not the
right place
to get the value of a component. The reason is simple: on a
postback
(submit) the component binding setter is called in the
restore view
phase where the value of the component is not yet set. In
this phase not
even the submitted value is yet set for the component.

On the first submit the value is set after your setter was
called.
Therefore you can't see it before the second submit.

If you are interested you can have a look at [1] for
details (I assume
you speak german).

regards
Michael

[1]: http://jsfatwork.irian.at/semistatic/jsf.html#idx:/jsf.html:2.6

Am 25.01.2010 14:35, schrieb schneidc:

Hi,

I tried both drop down menus, MyFaces's

HtmlSelectOneMenu and Trinidad's

SelectOneChoice and both seem to have the same problem

or at least I can't

understand their behaviour.

The menus are bound to an according object in a

managed bean and the setter

looks like this:

     public void

setSelectOne(CoreSelectOneChoice selectOne) {

         this.selectOne =

selectOne;

if(selectOne.getValue() != null)

System.out.println(selectOne.getValue().toString());

         else

     System.out.println("broker null");

     }

the tags:

     <tr:selectOneChoice id="menu0"
inlineStyle="margin-left: 20px"

binding="#{createTransactionModel.selectOne}">

         <tr:selectItem
label="Broker" value="broker" />

         <tr:selectItem
label="Customer" value="customer" />

     </tr:selectOneChoice>

The very first time I call a page I get "broker null"

as expected. Then I

push a button which causes a submit and the setter

get's called again but

although I SELECTED a value I still get "broker null".

When I push the

button a second time I finally get a not null value.


And if it wasn't confusing enough the behaviour

differs from App Server to

App Server. The above behaviour was observed on a

Websphere App Server. On a

Glassfish instead I get "broker null" when the page is

called for the first

time (ok so far) and when I hit a button
"broker null"
"broker != null"
as output straight one after another.


Can somebody explain to me this behaviour? Especially

why I only get a not

null value on the WAS after causing a submit a second

time?

Cheers
Simon