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.
*****************************************************************
