PROS:
* In a usecase where a field is disabled on the clientside (this means that
the disabled field is null) the application will throw the
ConversionException when trying to convert a null value.
A workaround for this issue is: instead of disabling the field, make it
readonly. BUT there is
On 8/26/07, Alex Objelean [EMAIL PROTECTED] wrote:
PROS:
* In a usecase where a field is disabled on the clientside (this means
that
the disabled field is null) the application will throw the
ConversionException when trying to convert a null value.
i do not think this is a valid argument.
i dont think this is needed. your custom converter should include a null
check.
But I do not use custom converter. In my case it is about a simple String or
Integer or whatever...
So, you suggest to create a custom converter for each case where I disable
the form component on the
On 8/27/07, Alex Objelean [EMAIL PROTECTED] wrote:
Maybe we can find a compromise regarding this issue?
how about you create a quickstart that demonstrates this, and then we can
play around with it and see what we can come up with.
-igor
If you believe that the usecase is obscure, shouldn't this approach to be
reconsidered? Or at least discussed a little bit more, before the final
release is done?
Thank you!
igor.vaynberg wrote:
i believe it was jonathan who had an obscure usecase that null input was
supposed to be
it is obscure but it still should be possible. anyway, you can discuss it
here if you like. for example you can list some pros and cons that you think
the current approach has.
-igor
On 8/15/07, Alex Objelean [EMAIL PROTECTED] wrote:
If you believe that the usecase is obscure, shouldn't this
I found a quick fix for my issue: instead of disabling the Textfield, I make
it readonly... still wondering why the change has been made in the convert()
method.
Matej Knopp-2 wrote:
At this point I don't know why the check was removed, but i suppose
there was a reason for it. I'm not sure
