Hi Jakob,
Actually this change has other implications, like the following one:
In a form, I use a double-SelectManyMenu. One lists all possible values,
and the other lists the selected values. Two buttons allow the user to
place a value from one menu to the other.
The business values are listed in a java Enum, and use a converter. To
make things clearer for our users, the values in the first menu, where all
possible values are stored, are separated with two "titles". These
elements actually are SelectItems, with a "-1" value, added as follows:
public List<SelectItem> buildComboContentForSomeBusinessValue() {
List<SelectItem> items = new ArrayList<SelectItem>();
items.add(new SelectItem("-1","Some title"));
items.addAll(buildSomeSelectItemsBasedOnMyBusinessValues());
items.add(new SelectItem("-1","Some other title"));
items.addAll(buildOtherSelectItemsBasedOnMyBusinessValues());
return items;
}
My converter does the following:
public Object getAsObject(FacesContext facesContext, UIComponent
uiComponent, String s) throws ConverterException {
if ("-1".equals( s)) {
return null;
}
return MyBusinessEnum.valueOf( s);
}
(and the same in the other way round, Enum -> String)
This way, if the user selects one of the titles, we do nothing with it.
But if the user selects one of the real business values, then it is
processed, added to a list, etc...
This behavior used to work with version 1.1.2, and does not anymore. That
because the converter is not called anymore during the validation. We're
comparing for equality "null" and "-1" which would map to the same value
if the converter was called, but are obviously different without
conversion. From where I stand, the validation process should not take the
responsability to decide if objects are the same or not when a converter
is involved, but should delegate the conversion to the converter before
testing for equality.
I now have two options: add the titles to the business enum, which is
ugly, or find a way to make the validation work again as it used to... If
you think about it, quite a lot of people add elements in a business
menus. Think of the "All" or "None" options that many menus display. In
that case, I guess (or... hope :-) that the developpers do not include
"All" and "None" values in their business enums...
Do you have any hints to help me work around this change? Or am I doing
something wrong here?
On another topic: since your are following the spec version with the first
two digits of MyFaces versions, shouldn't you make it a 4-digits version,
with the third incrementing when breaking changes occur, and the fourth
incrementing when you are simply patching the code? I'm not opposed to
breaking changes in the libs I include in my apps, there's no other way to
evolve sometimes... but I'd just like to know when it's going to happen...
:-)
Thanks again for your support,
Best regards,
Sébastien
Jakob Korherr <jakob.korh...@gmail.com>
Sent by: sethfromaust...@gmail.com
08.03.2010 17:20
Please respond to
"MyFaces Discussion" <users@myfaces.apache.org>
To
MyFaces Discussion <users@myfaces.apache.org>
cc
Subject
Re: Trouble upgrading from 1.1.2 to 1.1.7
Hi Sébastien,
It's great that you were able to figure out the real problem :)
To explain it a little further: the <f:selectItem itemValue="1" .../>
creates a SelectItem with the String value of "1". If you want to provide
an
Integer value you have to provide it via a property in a managed bean that
returns the integer 1. maybe also #{1} will work, but I'm not really
sure...
I totally agree that there should be a document (wiki-page etc.) that
describes such changes. Unfortunately this was far before my time..
However,
if we apply similar changes to MyFaces 2.0, I will write them down on a
wiki
page, I promise ;)
Regards,
Jakob
2010/3/8 <s.pen...@lombardodier.com>
> Hello Jakob,
>
> Don't worry for the delay, that's great to have support for this kind of
> problems :-)
>
> First, I changed all the attributes that did not work to String, so that
> the page worked again. Then I chose one of the attributes and tried the
> following configurations:
>
> - int property -> KO
> - Integer property -> KO
> - Integer property and explicit converter:
> (javax.faces.convert.IntegerConverter registered in my own
> faces-config.xml) -> KO
> - String property -> OK
>
> Since the field was mapping to a "greater or smaller than" filter value,
I
> had not set the page to display an error corresponding to this field. So
I
> added the following line to my JSPX:
> <ice:message for="myOperator" styleClass="errorMsg"/>
>
> With this line, I can now see an error message, saying that my value is
> not a valid option. Here is how the field is written in the JSPX:
>
> <ice:selectOneMenu value="#{listController.filter.myOperator}" id=
> "myOperator">
> <f:selectItem itemValue="1" itemLabel="#{msg.search_filter_greater}"
/>
> <f:selectItem itemValue="-1" itemLabel="#{msg.search_filter_less}" />
> </ice:selectOneMenu>
>
> I see the call in the IntegerConverter, and can trace it until it is in
> the UIInput.java class:
>
> if (!isValid()) return;
> validateValue(context, convertedValue);
> if (!isValid()) return;
>
> The first call to "isValid()" returns true, and the second call returns
> false.
>
> By digging a little bit further, I found this, in UISelectOne.java, in
> method "validateValue(FacesContext context, Object value)" :
> // selected value must match to one of the available options
> if (!_SelectItemsUtil.matchValue(value, new _SelectItemsIterator(this)))
> {
> _MessageUtils.addErrorMessage(context, this, INVALID_MESSAGE_ID, new
> Object[] {getId()});
> setValid(false);
> }
>
> The condition here returns true, meaning that the validation fails. And
> ever further down in SelectItemsUtil.java, method "matchValue(Object
> value, Iterator selectItemsIter)":
> Object itemValue = item.getValue();
> if (value==itemValue || (itemValue.equals(value))) {
> return true;
> }
>
> In this condition, the Integer value that has just been created is
tested
> for equality with the String value that is in the SelectItem. The
> validation obviously cannot pass. In version 1.1.2, the same method
> contained the following code:
>
> Object itemValue = item.getValue();
> if(converter != null && itemValue instanceof String)
> {
> itemValue = converter.getConvertedValue(context, (String)itemValue);
> }
> if (value==itemValue || value.equals(itemValue))
> {
> return true;
> }
>
> This code changed the value of the variable "itemValue" to the converted
> value when a converter was available, and thus tested two Integer
objects
> for equality.
> I think this explains why setting the property to String works in 1.1.7,
> and leaving the property as an int or Integer, as it used to work in
> 1.1.2, doesn't work anymore.
> Searching through MyFaces' JIRA, with a clearer view of the problem lead
> me to this issue: [1], which explicitly changed the code that is printed
> here above. Several persons pointed out the fact that this change of
> behavior would be an upgrade problem for users migrating MyFaces. But
> since the change was making MyFaces behave more closer to the RI, I
guess
> it made sense to do it anyway.
>
> More generally speaking, I think that somebody at MyFaces should build
and
> maintain a document listing all upgrade-breaking changes that are found
as
> the development goes on. It is time-consuming to have to diagnose a
> problem like I had to do, and seeing that the code has been changed
> knowing that it would cause upgrade problems is just plain annoying.
Maybe
> this document already exists, but my search for upgrade problems with
> MyFaces did not lead me to it.
>
> Anyway, thanks Jakob for your support :-)
>
> Best regards,
>
> Sébastien
>
> [1] http://issues.apache.org/jira/browse/MYFACES-1328
>
>
>
>
>
>
>
> Jakob Korherr <jakob.korh...@gmail.com>
> Sent by: sethfromaust...@gmail.com
>
>
> 06.03.2010 09:56
> Please respond to
> "MyFaces Discussion" <users@myfaces.apache.org>
>
>
>
> To
> MyFaces Discussion <users@myfaces.apache.org>
> cc
>
> Subject
> Re: Trouble upgrading from 1.1.2 to 1.1.7
>
>
>
>
>
>
> Hi Sébastien,
>
> Sorry for the long delay - I had to learn a lot last week for a
university
> exam...
>
> Anyway, the thing with iceSubmit() was just a guess. I thought that
maybe
> ICEfaces causes some kind of a wrong submit data or something like that.
> However, it really bugs me that this does not work out for you! A
version
> upgrade should not be a loss of functionality!
>
> The next thing you/we could take a look at is the conversion mechanism.
> Maybe this does not work right, because your String properties work
> (right?)
> and your int properties don't. Have you tried setting a converter
manually
> at the component which is bound to the int property? The standard
integer
> converter's class is javax.faces.convert.IntegerConverter. Altough this
> class is registered in the standard-faces-config.xml for type int and
> java.lang.Integer, it may not be applied (why ever..).
>
> Another thing you could try is changing the property from the native int
> type to java.lang.Integer. Maybe this will work.
>
> Hope this helps!
>
> Regards,
> Jakob
>
> 2010/3/3 <s.pen...@lombardodier.com>
>
> > Hi Jakob,
> >
> > I guess that the javascript in iceSubmit() might not the cause of the
> > problem... The int binding that used to work doesn't work anymore, and
> > this is what caused the interface to "freeze". Correcting the java
code
> to
> > accept a String made the interface work correctly again....
> >
> > I fail to understand how does the javascript iceSubmit() fits in
this...
> > but I certainly am not the most knowledgable person on the matter.
Could
> > you explain what makes you think that the javascript might be a good
> > suspect?
> >
> > Since I have a release planned in a quite short time, I won't be able
to
> > rewrite the whole form using only MyFaces components... sorry about
> > that... :( But I might have the time to build a sample-app that shows
> that
> > the binding that used to work doesn't work anymore. As I understood
> them,
> > the release notes of MyFaces do not show anything related to this
change
> > of behavior. Do you think it might be a bug?
> >
> > Regards,
> >
> > Sébastien
> >
> >
> >
> >
> >
> >
> >
> >
> > Jakob Korherr <jakob.korh...@gmail.com>
> > Sent by: sethfromaust...@gmail.com
> >
> >
> > 02.03.2010 23:39
> > Please respond to
> > "MyFaces Discussion" <users@myfaces.apache.org>
> >
> >
> >
> > To
> > MyFaces Discussion <users@myfaces.apache.org>
> > cc
> >
> > Subject
> > Re: Trouble upgrading from 1.1.2 to 1.1.7
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > You're welcome ;)
> >
> > Hmm. Maybe the submitting via the javascript function iceSubmit() does
> not
> > function properly. It's really hard to say from this point of view...
> >
> > Have you tried using some of the standard MyFaces components (without
> > ICEFaces)?
> >
> > Regrads,
> > Jakob
> >
> > 2010/3/2 <s.pen...@lombardodier.com>
> >
> > > Hello Jakob,
> > >
> > > Here is the generated HTML of (a part of) a search form. It includes
a
> > > "Bigger than/smaller than" field that was bound to an int in my Java
> > code.
> > >
> > > The binding was not working anymore, untill I modified the setter of
> the
> > > attribute to take a String and converted to an int afterwards (just
as
> a
> > > quick way of testing if a String binding would work).
> > >
> > > I then changed several other bindings similar to this one to use
> > Strings,
> > > and the app seems to run way better now :-) but anyway further
testing
> > > will be necessary.
> > >
> > > HTML:
> > >
> > > <tr class="icePnlGrdRow2">
> > > <td class="icePnlGrdCol editrQ" id="searchForm:_id1068-1-0">
> > > <label class="iceOutLbl bold"
> > > for="searchForm:aValueToFilter" id="searchForm:_id1075">Label of the
> > value
> > > to filter</label>
> > > </td>
> > >
> > > <td class="icePnlGrdCol editrR" id="searchForm:_id1068-1-1">
> > > <div class="icePnlGrp" id="searchForm:_id1076">
> > > <select style="" class="iceSelOneMnu"
> > > id="searchForm:valueToFilterOperator"
> > > name="searchForm:valueToFilterOperator"
> > > onblur="setFocus('');"
> > > onfocus="setFocus(this.id);" size="1">
> > > <option value="1">Bigger than or equal
> > > to</option>
> > > <option value="-1">Smaller than/option>
> > > </select>
> > >
> > > <input style="" class="iceInpTxt"
> > > id="searchForm:aValueToFilter" name="searchForm:aValueToFilter"
> > > onblur="setFocus('');"
> > > onfocus="setFocus(this.id);"
onkeypress="iceSubmit(form,this,event);"
> > > onmousedown="this.focus();"
> > > size="15" value="" type="text">
> > > <label class="iceOutLbl"
> id="searchForm:_id1079">
> > > unit of the value to filter</label>
> > >
> > > <span id="searchForm:_id1080"></span>
> > > </div>
> > > </td>
> > > </tr>
> > >
> > > Does it help?
> > >
> > > Thanks a lot for your help...
> > >
> > > Best regards,
> > >
> > > Sébastien
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Jakob Korherr <jakob.korh...@gmail.com>
> > > Sent by: sethfromaust...@gmail.com
> > >
> > >
> > > 01.03.2010 17:50
> > > Please respond to
> > > "MyFaces Discussion" <users@myfaces.apache.org>
> > >
> > >
> > >
> > > To
> > > MyFaces Discussion <users@myfaces.apache.org>
> > > cc
> > >
> > > Subject
> > > Re: Trouble upgrading from 1.1.2 to 1.1.7
> > >
> > >
> > >
> > >
> > >
> > >
> > > Can you provide some generated HTML (not JSP!!), which includes
> > components
> > > that do not work. This could be a great help!
> > >
> > > Regards,
> > > Jakob
> > >
> > > 2010/3/1 <s.pen...@lombardodier.com>
> > >
> > > > Hello,
> > > >
> > > > My guess is that the problem is more general than just a
javascript
> > > issue.
> > > >
> > > > In my previous message, I gave the "form submit" situation only as
> an
> > > > example. The problem actually touches more than just this: I
cannot
> > sort
> > > > my table content by clicking on one column header, I cannot switch
> > from
> > > a
> > > > StackPanel to another, etc...
> > > >
> > > > By searching a little bit further, I found out that the values
that
> I
> > > used
> > > > in combo boxes to show a "greater or smaller" choice (for example,
> age
> > > > greater or smaller than 30) are not bound to their java
counterpart
> > > > anymore. For example:
> > > >
> > > > <ice:selectOneMenu value="#{someController.filter.ageOperator}"
id=
> > > > "ageOperator">
> > > > <f:selectItem itemValue="1"
> itemLabel="#{msg.search_filter_greater}"
> > />
> > > > <f:selectItem itemValue="-1"
itemLabel="#{msg.search_filter_less}"
> />
> > > > </ice:selectOneMenu>
> > > >
> > > > This menu was bound to a Java integer as follows:
> > > >
> > > > private int ageOperator;
> > > >
> > > > With 1.1.7, the value is not bound anymore. I needed to change the
> > type
> > > of
> > > > the attribute in my Java class to String for the binding to work
> > again.
> > > Is
> > > > there a special converter that I should add, which was not needed
in
> > > 1.1.2
> > > > ? I can assure you that this runs fine with 1.1.2 :-)
> > > >
> > > > I am fairly new to MyFaces. Is there something I should do to make
> the
> > > > upgrade easier?
> > > >
> > > > Thanks a lot for your help :-)
> > > >
> > > > Sébastien
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Jakob Korherr <jakob.korh...@gmail.com>
> > > > Sent by: sethfromaust...@gmail.com
> > > >
> > > >
> > > > 01.03.2010 12:25
> > > > Please respond to
> > > > "MyFaces Discussion" <users@myfaces.apache.org>
> > > >
> > > >
> > > >
> > > > To
> > > > MyFaces Discussion <users@myfaces.apache.org>
> > > > cc
> > > >
> > > > Subject
> > > > Re: Trouble upgrading from 1.1.2 to 1.1.7
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Maybe there's a problem with the javascript that submits the form.
I
> > saw
> > > > However this is just a shot in the blue...
> > > >
> > > > Regards,
> > > > Jakob
> > > >
> > > > 2010/3/1 <s.pen...@lombardodier.com>
> > > >
> > > > > Hello,
> > > > >
> > > > > I am experiencing quite a lot of trouble while upgrading from
> > MyFaces
> > > > > 1.1.2 to 1.1.7.
> > > > >
> > > > > My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate
> > 3.4.0.
> > > > >
> > > > > The only thing that I changed in my Maven 2 build is the version
> of
> > > > > MyFaces.
> > > > > This had an impact on the following jars:
> > > > >
> > > > > Added:
> > > > > myfaces-api-1.1.7.jar
> > > > > myfaces-impl-1.1.7.jar
> > > > > commons-digester-1.8.jar
> > > > > commons-beanutils-1.8.0.jar
> > > > >
> > > > > Removed:
> > > > > myfaces-api-1.1.2.jar
> > > > > myfaces-impl-1.1.2.jar
> > > > > commons-digester-1.6.jar
> > > > > commons-beanutils-1.7.0.jar
> > > > > commons-codec-1.3.jar
> > > > >
> > > > > When I build and deploy my application in Weblogic 9.2.3, the
> deploy
> > > > goes
> > > > > fine, but the actions in the app do not work anymore.
> > > > > More precisely: as soon as I try to use JSF components like if
I
> > > submit
> > > > a
> > > > > form, then nothing happens. This behaviour can be observed with
> > > several
> > > > > browsers.
> > > > >
> > > > > I tried to find some upgrading guide but didn't find any guide
> > related
> > > > to
> > > > > these versions. And since the version change is minor, I
expected
> my
> > > > > application to run fine with the new jars.
> > > > >
> > > > > I tried also tried to override some jar versions, putting back
the
> > > > > Digester to version 1.6, and the BeanUtils to version 1.7.0, but
> > this
> > > > > didn't change anything. At this point, the only thing that had
> > changed
> > > > in
> > > > > my EAR were the two MyFaces jars.
> > > > >
> > > > > Another attempt to find the problem was to upgrade the version
> > > > gradually.
> > > > > I switched to MyFaces 1.1.4, and everything worked fine. That's
> when
> > I
> > > > > switched to MyFaces 1.1.5 that the problem appeared. However, I
> > > haven't
> > > > > seen anything in the changes from 1.1.4 to 1.1.5[1] that seems
> > > suspect.
> > > > >
> > > > > Is there some configuration changes that I might have missed? Or
> > some
> > > > > known compatibility problems regarding this upgrade? Again, I
> > couldn't
> > > > > find anything precisely related to these versions up to now, but
> I'm
> > > > still
> > > > > looking.
> > > > >
> > > > > Any help would be highly appreciated! :-)
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Sébastien
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10600&fixfor=12312310&sorter/field=summary&sorter/order=ASC&sorter/field=resolution&sorter/order=ASC&sorter/field=status&sorter/order=ASC&sorter/field=priority&sorter/order=DESC
>
> >
> > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > ************************ DISCLAIMER ************************
> > > > > This message is intended only for use by the person to
> > > > > whom it is addressed. It may contain information that is
> > > > > privileged and confidential. Its content does not
> > > > > constitute a formal commitment by Lombard Odier
> > > > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > > > If you are not the intended recipient of this message,
> > > > > kindly notify the sender immediately and destroy this
> > > > > message. Thank You.
> > > > >
*****************************************************************
> > > > >
> > > >
> > > >
> > > >
> > > > ************************ DISCLAIMER ************************
> > > > This message is intended only for use by the person to
> > > > whom it is addressed. It may contain information that is
> > > > privileged and confidential. Its content does not
> > > > constitute a formal commitment by Lombard Odier
> > > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > > If you are not the intended recipient of this message,
> > > > kindly notify the sender immediately and destroy this
> > > > message. Thank You.
> > > > *****************************************************************
> > > >
> > >
> > >
> > >
> > > ************************ DISCLAIMER ************************
> > > This message is intended only for use by the person to
> > > whom it is addressed. It may contain information that is
> > > privileged and confidential. Its content does not
> > > constitute a formal commitment by Lombard Odier
> > > Darier Hentsch & Cie or any of its branches or affiliates.
> > > If you are not the intended recipient of this message,
> > > kindly notify the sender immediately and destroy this
> > > message. Thank You.
> > > *****************************************************************
> > >
> >
> >
> >
> > ************************ DISCLAIMER ************************
> > This message is intended only for use by the person to
> > whom it is addressed. It may contain information that is
> > privileged and confidential. Its content does not
> > constitute a formal commitment by Lombard Odier
> > Darier Hentsch & Cie or any of its branches or affiliates.
> > If you are not the intended recipient of this message,
> > kindly notify the sender immediately and destroy this
> > message. Thank You.
> > *****************************************************************
> >
>
>
>
> ************************ DISCLAIMER ************************
> This message is intended only for use by the person to
> whom it is addressed. It may contain information that is
> privileged and confidential. Its content does not
> constitute a formal commitment by Lombard Odier
> Darier Hentsch & Cie or any of its branches or affiliates.
> If you are not the intended recipient of this message,
> kindly notify the sender immediately and destroy this
> message. Thank You.
> *****************************************************************
>
************************ DISCLAIMER ************************
This message is intended only for use by the person to
whom it is addressed. It may contain information that is
privileged and confidential. Its content does not
constitute a formal commitment by Lombard Odier
Darier Hentsch & Cie or any of its branches or affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*****************************************************************
