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. wicket keeps severside state, and
one of the requirements is that serverside state is in sync with client side
state. that means that component should be disabled on the serverside as
well - and when it is it will not attempt to process input - which is what
should really happen.
A workaround for this issue is: instead of disabling the field, make it
> readonly. BUT there is another problem: there are form components which
> cannot have readonly state on some browsers (for instance SELECT in IE).
> So
> the workaround is not suitable for all situations.
i dont think this is needed. your custom converter should include a null
check.
* It worked this way in wicket-1.2.x branch
i will buy that. but what we have done is created room for a new usecase -
converting null input to a non-null object. 1.2.6 didnt support that.
jonathan are you reading with us? what exactly was your usecase?
* IMHO conversion of null to null is a natural conversion.
apparently not _that_ natural, at least one someone had a usecase where it
wasnt.
-igor
CONS:
> * IMO none. Still curious about the usecase where you need null input to
> be
> converted to non null object.
>
> I would like this issue to be discussed a little bit more by the core
> developers and later to vote the change.
>
> Thank you!
>
>
> igor.vaynberg wrote:
> >
> > 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 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 converted to a nonnull object.
> >> >
> >> > -igor
> >> >
> >> >
> >> > On 8/14/07, Alex Objelean <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >>
> >> >>
> >> >> 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 whether we should support
> >> the
> >> >> > state when client and server are out of sync.
> >> >> >
> >> >> > -Matej
> >> >> >
> >> >> > On 8/14/07, Alex Objelean <[EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> This means that the component enable state must be always in sync
> >> with
> >> >> >> the
> >> >> >> client side state? Shouldn't it be set automatically as not
> enabled
> >> >> after
> >> >> >> the submit occurs? On the other hand, the same code worked great
> on
> >> >> the
> >> >> >> wicket-1.2.x branch..
> >> >> >>
> >> >> >> Please help!
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> Matej Knopp-2 wrote:
> >> >> >> >
> >> >> >> > I'm not sure if it's bug in wicket. So your <input> is
> disabled,
> >> but
> >> >> >> > the TextField component is not? That's not good, you need to
> >> disable
> >> >> >> > the TextField too in that case.
> >> >> >> >
> >> >> >> > -Matej
> >> >> >> >
> >> >> >> > On 8/14/07, Alex Objelean <[EMAIL PROTECTED]> wrote:
> >> >> >> >>
> >> >> >> >> After migrating from wicket-1.2.6 to wicket-1.3.0-beta2 I had
> >> the
> >> >> >> >> following
> >> >> >> >> problem:
> >> >> >> >>
> >> >> >> >> application throws ConversionException when trying to convert
> a
> >> >> null
> >> >> >> >> value
> >> >> >> >> of the Textfield wich is disabled on the clientside.
> >> >> >> >>
> >> >> >> >> I've take a look on the convert() method of the FormComponent
> >> class
> >> >> >> and
> >> >> >> >> noticed the difference from the 1.2.x branch which may cause
> the
> >> >> >> issue:
> >> >> >> >>
> >> >> >> >> This snippet of code is from 1.3.0-beta2
> >> >> >> >> [CODE]
> >> >> >> >> if (typeName == null) {
> >> >> >> >> //string conversion code
> >> >> >> >> } else {
> >> >> >> >> //type conversion code
> >> >> >> >> }
> >> >> >> >> [/CODE]
> >> >> >> >>
> >> >> >> >> This snippet of code is from 1.2.6
> >> >> >> >> [CODE]
> >> >> >> >> if (type == null) {
> >> >> >> >> //string conversion code
> >> >> >> >> } else if (!Strings.isEmpty(getInput())) {
> >> >> >> >> //type conversion code
> >> >> >> >> }
> >> >> >> >> [/CODE]
> >> >> >> >>
> >> >> >> >> As you can see, in the 1.3.0-beta2 version, the conversion
> does
> >> not
> >> >> >> check
> >> >> >> >> if
> >> >> >> >> the getInput() is an empty string before performing type
> >> >> conversion.
> >> >> I
> >> >> >> >> wonder if it is a bug, or it is something that I missed?
> >> >> >> >>
> >> >> >> >> Thank you!
> >> >> >> >> Alex
> >> >> >> >> --
> >> >> >> >> View this message in context:
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12140062
> >> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com
> .
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >>
> ---------------------------------------------------------------------
> >> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12141596
> >> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12157292
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12175844
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12342339
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
