Null vs empty string is not the only one case, the point I'm trying to make
here:
whenever the JSF framework is applying some data conversion (either the
converter was explicitly declared or not), it may (should) remember that
conversion rule, so that when that same page is submitted, the framework (I
mean JSF) will compare (*for the purpose of firing changeValueEvent*) *not
the original valu*e with the new value but the* converted original
value*with the new value.
Yes this is an old issue with all previous frameworks, but I thought JSF
could be better. And thinking of the declared converters, cann't I find all
converters for a given UIComponent using JSF API. I did not try but I
thought it's doable.
vlad
On 7/6/07, Bryan Basham <[EMAIL PROTECTED]> wrote:
The problem you are experiencing is true for any Java/Web
framework. An HTTP request parameter does not understand
what a Java null is but always uses the empty string "". So
somewhere in your application (or framework) you have to
handle the conversion from "" to null.
When it comes to String values, null is not the same as ""
so I would recommend that your backing beans be populated
with "" instead of null when dealing with JSF. Alternatively,
you could create a NullStringConverter which converts from
"" to null.
When it comes to non-String values, then your converter should
return null from the getAsObject method when an "" is the
request parameter.
-Bryan
vlad10 wrote:
> I'm fresh with JSF,
> just started building some prototypes with facelets 1.1.11, myfaces
> 1.1.3/tomahawk 1.1.3.
>
> I'm getting this general feeling that the framework is missing some
> important feature.
> I may create an inputText and populate it with a null value, the
framework
> conviniently will convert it into an empty string and populate my page.
> However, on submit the valueChangeListener will fire with the reason
that
> null is not the same as an empty string.
> I have another example. This the initial value is not null. I may
explicitly
> add a converter to that field, so the value stored in POJO as
jva.util.Date
> or as a BigDecimal or anything else will be nicely displayed on the
screen,
> but I'll face again the unwanted behavior of my valueChangeListener.
> For the time being, I'm trying to compensate this deficiency in my app
by
> adding some filtering in a utility class. At the moment it's in the
> beginning, just checking null/empty string case:
>
> /**
> * UIInput value is never null when submitted, but the POJO is
always
> * initialized with nulls. This creates a false alarm by
> valueChangeListeners.
> * This method tries to compensate this deficiency.
> * @param input
> * @param rec
> * @return
> */
> public static boolean isValueChanged(UIInput input, Object pojo) {
> String name = input.getId();
> Object val = BeanUtil.getBeanValue(pojo,name);
> if (val == null)
> if(StringUtils.isEmpty(input.getValue().toString()))
> return false;
> else
> return true;
> return (input.getValue().toString().compareTo(val.toString()) !=
0);
> }
>
> My question: am I missing something????
> Do I really need to add another layer in my app, I may call it something
> like JSF Frendly POJOs. I may perform all necessary conversions right
there
> when moving data from DB to the screen, and then on submit perform the
> opposit conversion when moving data back. I hope I can avoid that.
> Is not it possible for a framework to 'remember' not just an oldValue,
but
> also the conversion performed, so prior to comparing old/new values it
would
> apply that same converter to the old value???
> I think, this part has been missed.
>
> thanks
> vlad
>
