Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-27 Thread Alex Objelean 

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 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.
* It worked this way in wicket-1.2.x branch
* IMHO conversion of null to null is a natural conversion. 

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.

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-27 Thread Igor Vaynberg 
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]

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-27 Thread Alex Objelean 



 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 server-side?

Also, keeping in sync client-side with server-side, means that I need to
make an ajax round-trip just to update the field disable state on the
server.. IMO it is unnecessary overhead.

Maybe we can find a compromise regarding this issue? 
-- 
View this message in context: 
http://www.nabble.com/Wicket-1.3-beta2-validation-%28conversion%29-bug--tf4265733.html#a12342815
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-27 Thread Igor Vaynberg 
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

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-16 Thread Alex Objelean 

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]

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-16 Thread Igor Vaynberg 
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]

Re: Wicket-1.3-beta2 validation (conversion) bug?

2007-08-15 Thread Alex Objelean 


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]