Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
To sum up discussion, I understood that trimming is going to be default behaviour on text fields (soon) ? Correct ? Ari S. - Original Message - From: Ari Suutari [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 3:25 PM Subject: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
just committed it:FormComponentprotected Object convertValue(String value) throws ConversionException { return value != null?value.trim():null; }so if you don't want trimming, override that method and return directly the value.
I think it is a better default.We could make a global property to switch it again, but personally i don't see many uses for that.johanOn 3/10/06,
Ari Suutari [EMAIL PROTECTED] wrote:
To sum up discussion, I understood that trimming is goingto be default behaviour on text fields (soon) ? Correct ?Ari S.- Original Message -From: Ari Suutari
[EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Monday, March 06, 2006 3:25 PMSubject: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory),
but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check).Ari S.
--- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___ Wicket-user mailing list Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
By the way.That method is already overridden by many other formcomponents like RadioChoice, DropDownChoice or CheckBoxAlso when a textfield has a type specified it will also not fall into that method. because the type conversion through the convertor
will happen instead.So it only happens for textfieds without a type specified.johanOn 3/10/06, Johan Compagner
[EMAIL PROTECTED] wrote:just committed it:
FormComponentprotected Object convertValue(String value) throws ConversionException { return value != null?value.trim():null;
}so if you don't want trimming, override that method and return directly the value.
I think it is a better default.We could make a global property to switch it again, but personally i don't see many uses for that.johan
On 3/10/06,
Ari Suutari [EMAIL PROTECTED] wrote:
To sum up discussion, I understood that trimming is goingto be default behaviour on text fields (soon) ? Correct ?Ari S.- Original Message -From: Ari Suutari
[EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Monday, March 06, 2006 3:25 PM
Subject: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory),
but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check).Ari S.
--- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___ Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of something
else.
getInput would be fine if we were just starting development. But we have a
big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we have
a big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure that
there are plenty of use cases where manipulating also the value would be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of different
interfaces
that one can use to get between things and alter the behaviour for local
needs
without creating a derived component of each standard component. This is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but do we need this in core? its a trivial subclass, why not create
it
in
your own codebase?
if you guys want it in core you can have it, just asking.
-Igor
On 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
+1 for this solution. this seems to be the cleanest implementation
to
me and puts the responsibility on the developer to *use* the
correct
component.
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess thats true. you can create a subclass TrimmingTextField
that
overrides getInput() and trims it.
-Igor
On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
So before the input goes into the
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Ari, what about using AOP?
Eelco
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of something
else.
getInput would be fine if we were just starting development. But we have a
big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we have
a big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure that
there are plenty of use cases where manipulating also the value would be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of different
interfaces
that one can use to get between things and alter the behaviour for local
needs
without creating a derived component of each standard component. This is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but do we need this in core? its a trivial subclass, why not create
it
in
your own codebase?
if you guys want it in core you can have it, just asking.
-Igor
On 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
+1 for this solution. this seems to be the cleanest implementation
to
me and puts the responsibility on the developer to *use* the
correct
component.
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess thats true. you can create a
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Hi,
Yes. After all, the name is Converter, not TypeConverter.
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:25 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of something
else.
getInput would be fine if we were just starting development. But we have a
big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we have
a big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure that
there are plenty of use cases where manipulating also the value would be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of different
interfaces
that one can use to get between things and alter the behaviour for local
needs
without creating a derived component of each standard component. This is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but do we need this in core? its a trivial subclass, why not create
it
in
your own codebase?
if you guys want it in core you can have it, just asking.
-Igor
On 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
+1 for this solution. this seems to be the cleanest implementation
to
me and puts the responsibility on the developer to *use* the
correct
component.
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess thats true. you can create a subclass TrimmingTextField
that
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
this is not a kind of a problem i would want to be tracing for, especially as a user. you add your own string converter and that suddenly breaks some internal feature that you dont even know about, or maybe it even breaks some 3rd party components.
i know i feel strongly about this one. how strong do you feel? should we have a vote?-IgorOn 3/9/06, Eelco Hillenius
[EMAIL PROTECTED] wrote:It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hatand look at that API, *I* would expect conversion to happen from inputparameters to my model properties regardless whether it has the target
type or not.EelcoOn 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: this might have nasty side effects that we do not see right now. for example
converters are going to start running on things they werent running on before. how is this going to affect existing applications? furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they are intended to be /type/ converters by looking at the javadoc of IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to affect places in wicket's core outside form processing? i still dont think this is the right approach. we should think of something
else. getInput would be fine if we were just starting development. But we have a big application going to production soon and I'm seeking some kind of another
alternative than telling all developers to change their TextFields to MyTrimmerTextFields. so why are you just now thinking about this? sounds to me like you are dealing with this issue too late. (not that we are not willing to help you)
-Igor On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote: I agree with Ari and I am not against removing that check.
Eelco On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, getInput would be fine if we were just starting development. But we have
a big application going to production soon and I'm seeking some kind of another alternative than telling all developers to change their TextFields to MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just failed on this one. Why should you think Converter only as datatype converter ? I'm sure that there are plenty of use cases where manipulating also the value would be
handy. Also, I don't think that removing the short-circuit done by isAssignableFrom woundn't be a performace problem ? What I have liked about wicket a lot is that there are a lot of different
interfaces that one can use to get between things and alter the behaviour for local needs without creating a derived component of each standard component. This is also
the reason I'm insisting about similar solution here. Ari S. - Original Message - From: Igor Vaynberg
[EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Wednesday, March 08, 2006 9:23 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)but is it really then a conversion? why run a Integer-Integer conversion or a String-String conversion? then you are really warping the converter
into an input postprocessor. why not create a simple subclass of textfield and override getInput() ? -IgorOn 3/7/06, Ari Suutari
[EMAIL PROTECTED] wrote: Could someone also take a look at Converter so it could be used ? I mean this line in
Converter.java: // Catch all cases where value is already the right type if (c.isAssignableFrom(value.getClass())) { return value;
} This is some kind of a optimization, right ? But as a side effect it makes it impossible to do any conversion on textfield input if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ? Ari S. - Original Message - From: Eelco Hillenius
[EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,as that's one of the key points of Wicket imo :) Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:but do we need this in core? its a trivial subclass, why not create
it inyour own codebase? if you guys want it in core you can have it, just asking.
-Igor On 3/7/06, Ryan Sonnek [EMAIL PROTECTED]
wrote: +1 for this solution.this seems to be the cleanest implementation to me and puts the responsibility on the developer to *use* the
correct component. On 3/7/06, Igor Vaynberg [EMAIL PROTECTED]
wrote: i guess thats
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
I don't feel as strongly, so need to to vote here. It's been in there
a long time and it isn't really wrong either. So what other options
does Ari have - besides AOP.
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this is not a kind of a problem i would want to be tracing for, especially
as a user. you add your own string converter and that suddenly breaks some
internal feature that you dont even know about, or maybe it even breaks some
3rd party components.
i know i feel strongly about this one. how strong do you feel? should we
have a vote?
-Igor
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for
example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they
are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of
something
else.
getInput would be fine if we were just starting development. But we have
a
big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help
you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we
have
a big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just
failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure
that
there are plenty of use cases where manipulating also the value would be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of
different
interfaces
that one can use to get between things and alter the behaviour for local
needs
without creating a derived component of each standard component. This is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer
conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield
and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components
more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
AOP would be one solution, but haven't needed it so far with wicket, because
there have always been elegant interfaces that I have been able to use to
make things work like we want. That wouldn't be wicket's way of doing things,
would it ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:27 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
Ari, what about using AOP?
Eelco
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of something
else.
getInput would be fine if we were just starting development. But we have a
big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we have
a big
application going to production soon and I'm seeking some kind of another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure that
there are plenty of use cases where manipulating also the value would be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of different
interfaces
that one can use to get between things and alter the behaviour for local
needs
without creating a derived component of each standard component. This is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but do we need this in core? its a trivial subclass, why not create
it
in
your own codebase?
if you guys want it in core you can have it, just asking.
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Whats the risk here ? The default StringConverter in wicket does nothing
when invoked for String-String conversion.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:42 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
this is not a kind of a problem i would want to be tracing for, especially
as a user. you add your own string converter and that suddenly breaks some
internal feature that you dont even know about, or maybe it even breaks some
3rd party components.
i know i feel strongly about this one. how strong do you feel? should we
have a vote?
-Igor
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for
example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they
are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter
that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of
something
else.
getInput would be fine if we were just starting development. But we
have a
big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help
you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we
have
a big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just
failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure
that
there are plenty of use cases where manipulating also the value would
be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of
different
interfaces
that one can use to get between things and alter the behaviour for
local
needs
without creating a derived component of each standard component. This
is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer
conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield
and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I
think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components
more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Another thing you can do is copy 'n paste Converter, make your
adjustement, and use that as the application wide converter. I think
everyone is happy then, and I don't think it is a class that'll change
often if ever.
Eelco
On 3/9/06, Ari Suutari [EMAIL PROTECTED] wrote:
Whats the risk here ? The default StringConverter in wicket does nothing
when invoked for String-String conversion.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:42 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
this is not a kind of a problem i would want to be tracing for, especially
as a user. you add your own string converter and that suddenly breaks some
internal feature that you dont even know about, or maybe it even breaks some
3rd party components.
i know i feel strongly about this one. how strong do you feel? should we
have a vote?
-Igor
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for
example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they
are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter
that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of
something
else.
getInput would be fine if we were just starting development. But we
have a
big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help
you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we
have
a big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just
failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure
that
there are plenty of use cases where manipulating also the value would
be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of
different
interfaces
that one can use to get between things and alter the behaviour for
local
needs
without creating a derived component of each standard component. This
is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer
conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield
and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I
think).
Maybe just drop those lines ?
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
This was also one idea that I considered. However, as it is more than just a one or two lines of code I decided to start this discussion in order to find a more elegant way. If you think about real-world applications, I would say that on-one wants to sit anwering support calls about odd incidents that occur because user's fields has some invisible spaces after value. I have been involved with form-based applications in several companies, for many years and always the policy has been to trim trailing blanks from fields. Otherwise the users will just get confused. Ari S. - Original Message - From: Eelco Hillenius [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Thursday, March 09, 2006 10:58 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) Another thing you can do is copy 'n paste Converter, make your adjustement, and use that as the application wide converter. I think everyone is happy then, and I don't think it is a class that'll change often if ever. Eelco On 3/9/06, Ari Suutari [EMAIL PROTECTED] wrote: Whats the risk here ? The default StringConverter in wicket does nothing when invoked for String-String conversion. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Thursday, March 09, 2006 10:42 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this is not a kind of a problem i would want to be tracing for, especially as a user. you add your own string converter and that suddenly breaks some internal feature that you dont even know about, or maybe it even breaks some 3rd party components. i know i feel strongly about this one. how strong do you feel? should we have a vote? -Igor On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: It's potentially dangerous, second that. But the argument of whether it is a good use of converters or not aside, when I put on my user hat and look at that API, *I* would expect conversion to happen from input parameters to my model properties regardless whether it has the target type or not. Eelco On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: this might have nasty side effects that we do not see right now. for example converters are going to start running on things they werent running on before. how is this going to affect existing applications? furthermore afaict the intention behind converters was to have a generic /type/ conversion framework for use inside wicket core. you can see they are intended to be /type/ converters by looking at the javadoc of IConverter.convert(Object, Class). how is a trimming string converter that is running on values that are already strings and trimming them going to affect places in wicket's core outside form processing? i still dont think this is the right approach. we should think of something else. getInput would be fine if we were just starting development. But we have a big application going to production soon and I'm seeking some kind of another alternative than telling all developers to change their TextFields to MyTrimmerTextFields. so why are you just now thinking about this? sounds to me like you are dealing with this issue too late. (not that we are not willing to help you) -Igor On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote: I agree with Ari and I am not against removing that check. Eelco On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, getInput would be fine if we were just starting development. But we have a big application going to production soon and I'm seeking some kind of another alternative than telling all developers to change their TextFields to MyTrimmerTextFields. Converter interface has been very handy for me before, but it just failed on this one. Why should you think Converter only as datatype converter ? I'm sure that there are plenty of use cases where manipulating also the value would be handy. Also, I don't think that removing the short-circuit done by isAssignableFrom woundn't be a performace problem ? What I have liked about wicket a lot is that there are a lot of different interfaces that one can use to get between things and alter the behaviour for local needs without creating a derived component of each standard component. This is also the reason I'm insisting about similar solution here. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Wednesday, March 08, 2006 9:23 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) but is it really then a conversion? why run a Integer-Integer conversion or a String-String conversion? then you are really warping the converter into an
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Could you make Converter not final, so I could subclass it and override convert
?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:58 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
Another thing you can do is copy 'n paste Converter, make your
adjustement, and use that as the application wide converter. I think
everyone is happy then, and I don't think it is a class that'll change
often if ever.
Eelco
On 3/9/06, Ari Suutari [EMAIL PROTECTED] wrote:
Whats the risk here ? The default StringConverter in wicket does nothing
when invoked for String-String conversion.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:42 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
this is not a kind of a problem i would want to be tracing for, especially
as a user. you add your own string converter and that suddenly breaks some
internal feature that you dont even know about, or maybe it even breaks some
3rd party components.
i know i feel strongly about this one. how strong do you feel? should we
have a vote?
-Igor
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user hat
and look at that API, *I* would expect conversion to happen from input
parameters to my model properties regardless whether it has the target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now. for
example
converters are going to start running on things they werent running on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a generic
/type/ conversion framework for use inside wicket core. you can see they
are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string converter
that
is running on values that are already strings and trimming them going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of
something
else.
getInput would be fine if we were just starting development. But we
have a
big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you are
dealing with this issue too late. (not that we are not willing to help
you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But we
have
a big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it just
failed
on this one.
Why should you think Converter only as datatype converter ? I'm sure
that
there are plenty of use cases where manipulating also the value would
be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of
different
interfaces
that one can use to get between things and alter the behaviour for
local
needs
without creating a derived component of each standard component. This
is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Wednesday, March 08, 2006 9:23 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe
at beginning)
but is it really then a conversion? why run a Integer-Integer
conversion
or
a String-String conversion? then you are really warping the converter
into
an input postprocessor. why not create a simple subclass of textfield
and
override getInput() ?
-Igor
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
This is a great idea ! Thanks !
Ari S.
- Original Message -
From: Johan Compagner [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 12:29 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
We could make it non final or make a delegate.
class MyConverter implements IConverter
{
IConverter delegate = new Converter();
convert(Object value, Class clss)
{
if(value instanceof String and clss == String.class)
{
return value.trim();
}
else
{
return delegate.convert(value,clss);
}
}
}
On 3/9/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could you make Converter not final, so I could subclass it and override
convert ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:58 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe
at beginning)
Another thing you can do is copy 'n paste Converter, make your
adjustement, and use that as the application wide converter. I think
everyone is happy then, and I don't think it is a class that'll change
often if ever.
Eelco
On 3/9/06, Ari Suutari [EMAIL PROTECTED] wrote:
Whats the risk here ? The default StringConverter in wicket does
nothing
when invoked for String-String conversion.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Thursday, March 09, 2006 10:42 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and
maybe at beginning)
this is not a kind of a problem i would want to be tracing for,
especially
as a user. you add your own string converter and that suddenly breaks
some
internal feature that you dont even know about, or maybe it even breaks
some
3rd party components.
i know i feel strongly about this one. how strong do you feel? should
we
have a vote?
-Igor
On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
It's potentially dangerous, second that. But the argument of whether
it is a good use of converters or not aside, when I put on my user
hat
and look at that API, *I* would expect conversion to happen from
input
parameters to my model properties regardless whether it has the
target
type or not.
Eelco
On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
this might have nasty side effects that we do not see right now.
for
example
converters are going to start running on things they werent running
on
before. how is this going to affect existing applications?
furthermore afaict the intention behind converters was to have a
generic
/type/ conversion framework for use inside wicket core. you can see
they
are
intended to be /type/ converters by looking at the javadoc of
IConverter.convert(Object, Class). how is a trimming string
converter
that
is running on values that are already strings and trimming them
going to
affect places in wicket's core outside form processing?
i still dont think this is the right approach. we should think of
something
else.
getInput would be fine if we were just starting development. But
we
have a
big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
so why are you just now thinking about this? sounds to me like you
are
dealing with this issue too late. (not that we are not willing to
help
you)
-Igor
On 3/8/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I agree with Ari and I am not against removing that check.
Eelco
On 3/8/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
getInput would be fine if we were just starting development. But
we
have
a big
application going to production soon and I'm seeking some kind of
another
alternative
than telling all developers to change their TextFields to
MyTrimmerTextFields.
Converter interface has been very handy for me before, but it
just
failed
on this one.
Why should you think Converter only as datatype converter ? I'm
sure
that
there are plenty of use cases where manipulating also the value
would
be
handy.
Also, I don't think that removing the short-circuit done by
isAssignableFrom
woundn't be a performace problem ?
What I have liked about wicket a lot is that there are a lot of
different
interfaces
that one can use to get between things and alter the behaviour
for
local
needs
without creating a derived component of each standard component.
This
is
also
the reason I'm insisting about similar solution here.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To:
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Of course. If you don't want all your textfields to trim your input by default, but instead have the input applied to your models exactly as it was provided, it is nice to be able to turn it off application wide. Eelco Because does it make sense to globally set it off? why would you do that? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
then create a subclass and use that instead :)-IgorOn 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:Of course. If you don't want all your textfields to trim your input by default, but instead have the input applied to your models exactly asit was provided, it is nice to be able to turn it off applicationwide.Eelco Because does it make sense to globally set it off? why would you do that?---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
when do you want that?I think 99% of all the text fields don't want trailing or leading spaces.So you can make it an options but then suddenly you have to do it the other way aroundif you do want trimming. But we can make it an option, i don't mind, i just think it is not really needed as an option.johanOn 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote:Of course. If you don't want all your textfields to trim your input by default, but instead have the input applied to your models exactly asit was provided, it is nice to be able to turn it off applicationwide.Eelco Because does it make sense to globally set it off? why would you do that?---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
That works for single cases, just as it would have worked for single cases for Ari. But whether you want to have trimming applied or not is also a cross cutting concern. Eelco On 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: then create a subclass and use that instead :) -Igor On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Of course. If you don't want all your textfields to trim your input by default, but instead have the input applied to your models exactly as it was provided, it is nice to be able to turn it off application wide. Eelco Because does it make sense to globally set it off? why would you do that? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
the only reason it didnt work for Ari was because he already created his application and only now is thinking about trimming.we say we trim all textfields by default, if you want to break out of it either override wherever needed or use a subclass. i dont see why we need some global option for something as simple as this. maybe for backwards compat with older apps, in that case we can add an option, deprecate it, and remove it post 1.2 release.-Igor On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: That works for single cases, just as it would have worked for singlecases for Ari. But whether you want to have trimming applied or not isalso a cross cutting concern.EelcoOn 3/9/06, Igor Vaynberg [EMAIL PROTECTED] wrote: then create a subclass and use that instead :) -Igor On 3/9/06, Eelco Hillenius [EMAIL PROTECTED] wrote: Of course. If you don't want all your textfields to trim your input by default, but instead have the input applied to your models exactly as it was provided, it is nice to be able to turn it off application wide. Eelco Because does it make sense to globally set it off? why would you do that? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user ---This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!http://sel.as-us.falkag.net/sel?cmdlnkkid0944bid$1720dat1642 ___Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
a trim flag on what?Form component? I don't like that what does it do for non text fields?trimming should belong in a model. For example a ModelWrapper where you put youre real models in.johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi,setTrimValue flag would be great (maybe there should be settingsfor left/right trim ?).Model might be also a working solution, but somehow I feel thatthis kind of task belongs to upper layer. Ari S.- Original Message -From: Igor Vaynberg [EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Monday, March 06, 2006 7:11 PMSubject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think?if not you can write a model that trims for you on setObject()-IgorOn 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user---This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642___Wicket-user mailing list Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
You also could use a Converter for this i guess.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:Hi,But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simpleinput cleanup is the user interface layer:- Let's say I have a model, which has field called code.- If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It isvery easy to accidentally put them there with copy paste, for example.- However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote.Besides, who it would harm if TextField TextArea had a flaglike this ? Nobody forces one to use it.Ari S.- Original Message - From: Johan Compagner [EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)a trim flag on what?Form component?I don't like that what does it do for non text fields?trimming should belong in a model. For example a ModelWrapper where you put youre real models in.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user--- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan?-IgorOn 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:Hi,But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simpleinput cleanup is the user interface layer:- Let's say I have a model, which has field called code.- If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It isvery easy to accidentally put them there with copy paste, for example.- However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote.Besides, who it would harm if TextField TextArea had a flaglike this ? Nobody forces one to use it.Ari S.- Original Message - From: Johan Compagner [EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)a trim flag on what?Form component?I don't like that what does it do for non text fields?trimming should belong in a model. For example a ModelWrapper where you put youre real models in.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
So before the input goes into the required/type conversion and validators we first trim itwhen that flag is set?. he also could just overwrite getInput() and trim the text when called.johan On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan?-Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:Hi,But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simpleinput cleanup is the user interface layer:- Let's say I have a model, which has field called code.- If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It isvery easy to accidentally put them there with copy paste, for example.- However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote.Besides, who it would harm if TextField TextArea had a flaglike this ? Nobody forces one to use it.Ari S.- Original Message - From: Johan Compagner [EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)a trim flag on what?Form component?I don't like that what does it do for non text fields?trimming should belong in a model. For example a ModelWrapper where you put youre real models in.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
i guess thats true. you can create a subclass TrimmingTextField that overrides getInput() and trims it.-IgorOn 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: So before the input goes into the required/type conversion and validators we first trim itwhen that flag is set?. he also could just overwrite getInput() and trim the text when called. johan On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan?-Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:Hi,But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simpleinput cleanup is the user interface layer:- Let's say I have a model, which has field called code.- If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It isvery easy to accidentally put them there with copy paste, for example.- However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote.Besides, who it would harm if TextField TextArea had a flaglike this ? Nobody forces one to use it.Ari S.- Original Message - From: Johan Compagner [EMAIL PROTECTED]To: wicket-user@lists.sourceforge.netSent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)a trim flag on what?Form component?I don't like that what does it do for non text fields?trimming should belong in a model. For example a ModelWrapper where you put youre real models in.johanOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing listWicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
but do we need this in core? its a trivial subclass, why not create it in your own codebase?if you guys want it in core you can have it, just asking.-IgorOn 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote: +1 for this solution.this seems to be the cleanest implementation tome and puts the responsibility on the developer to *use* the correctcomponent.On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i guess thats true. you can create a subclass TrimmingTextField that overrides getInput() and trims it. -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: So before the input goes into the required/type conversion and validators we first trim it when that flag is set?. he also could just overwrite getInput() and trim the text when called.johan On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan? -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
I don't think we need it in core. Maybe as an example somewhere. We have to get our users get used to working with custom components more, as that's one of the key points of Wicket imo :) Eelco On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: but do we need this in core? its a trivial subclass, why not create it in your own codebase? if you guys want it in core you can have it, just asking. -Igor On 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote: +1 for this solution. this seems to be the cleanest implementation to me and puts the responsibility on the developer to *use* the correct component. On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i guess thats true. you can create a subclass TrimmingTextField that overrides getInput() and trims it. -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: So before the input goes into the required/type conversion and validators we first trim it when that flag is set?. he also could just overwrite getInput() and trim the text when called. johan On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan? -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
+1 for this solution. this seems to be the cleanest implementation to me and puts the responsibility on the developer to *use* the correct component. On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i guess thats true. you can create a subclass TrimmingTextField that overrides getInput() and trims it. -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: So before the input goes into the required/type conversion and validators we first trim it when that flag is set?. he also could just overwrite getInput() and trim the text when called. johan On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only. are you opposed to that also Johan? -Igor On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote: You also could use a Converter for this i guess. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
I tried to use Converter at first, of course. But it doesn't work, since string-string -conversion bypasses things. (read the end of this e-mail) Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 3:44 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) You also could use a Converter for this i guess. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
I forgot to mention that: Converter would have been my preferred solution, because with it I could have easily modified trimming behavour of all my user interface components. So if this can be made to work it would be great. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 3:44 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) You also could use a Converter for this i guess. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple input cleanup is the user interface layer: - Let's say I have a model, which has field called code. - If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this: m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag like this ? Nobody forces one to use it. Ari S. - Original Message - From: Johan Compagner [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) a trim flag on what? Form component? I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper where you put youre real models in. johan On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, setTrimValue flag would be great (maybe there should be settings for left/right trim ?). Model might be also a working solution, but somehow I feel that this kind of task belongs to upper layer. Ari S. - Original Message - From: Igor Vaynberg [EMAIL PROTECTED] To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning) this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think? if not you can write a model that trims for you on setObject() -Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi, What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end ? I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anything if String is being assigned to String field in model (it uses isAssignableFrom for this check). Ari S. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
Could someone also take a look at Converter so it could be used ?
I mean this line in Converter.java:
// Catch all cases where value is already the right type
if (c.isAssignableFrom(value.getClass()))
{
return value;
}
This is some kind of a optimization, right ? But as a side effect
it makes it impossible to do any conversion on textfield input
if it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?
Ari S.
- Original Message -
From: Eelco Hillenius [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 7:22 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at
beginning)
I don't think we need it in core. Maybe as an example somewhere. We
have to get our users get used to working with custom components more,
as that's one of the key points of Wicket imo :)
Eelco
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
but do we need this in core? its a trivial subclass, why not create it in
your own codebase?
if you guys want it in core you can have it, just asking.
-Igor
On 3/7/06, Ryan Sonnek [EMAIL PROTECTED] wrote:
+1 for this solution. this seems to be the cleanest implementation to
me and puts the responsibility on the developer to *use* the correct
component.
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i guess thats true. you can create a subclass TrimmingTextField that
overrides getInput() and trims it.
-Igor
On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
So before the input goes into the required/type conversion and
validators
we first trim it
when that flag is set?.
he also could just overwrite getInput() and trim the text when called.
johan
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote:
i was also thinking a trim flag on the textfield and textarea only.
are
you opposed to that also Johan?
-Igor
On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
You also could use a Converter for this i guess.
johan
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
But simple validation is already on wicket level. Of course we
could
argue on this, but I really think that right place for simple
input cleanup is the user interface layer:
- Let's say I have a model, which has field called code.
- If user types new value for this in a field, I (and even user,
I
think)
excepts that invisible blanks at end of code are removed. It
is
very easy to accidentally put them there with copy paste,
for
example.
- However, if I code something like this: m.setCode(ZAP ); I
sure
except that it is stored excactly as I wrote.
Besides, who it would harm if TextField TextArea had a flag
like this ? Nobody forces one to use it.
Ari S.
- Original Message -
From: Johan Compagner [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Tuesday, March 07, 2006 11:35 AM
Subject: Re: [Wicket-user] TextField and trimming blanks at end
(and
maybe at beginning)
a trim flag on what?
Form component?
I don't like that what does it do for non text fields?
trimming should belong in a model. For example a ModelWrapper
where
you put
youre real models in.
johan
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
setTrimValue flag would be great (maybe there should be
settings
for left/right trim ?).
Model might be also a working solution, but somehow I feel
that
this kind of task belongs to upper layer.
Ari S.
- Original Message -
From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net
Sent: Monday, March 06, 2006 7:11 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at
end
(and maybe
at beginning)
this should be a flag on the textfield so you can call
setTrimValue(boolean)
what do others think?
if not you can write a model that trims for you on setObject()
-Igor
On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi,
What might be the simplest way to change behaviour of whole
wicket
application
so that TextField have their input trimmed of blanks at end
?
I tried to do this via converters (I have my own converter
factory),
but it didn't work because Converter.convert doesn't do
anything
if String is being assigned to String field in model (it
uses
isAssignableFrom
for this check).
Ari S.
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
but is it really then a conversion? why run a Integer-Integer conversion or a String-String conversion? then you are really warping the converter into an input postprocessor. why not create a simple subclass of textfield and override getInput() ?
-IgorOn 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Could someone also take a look at Converter so it could be used ?I mean this line in Converter.java:// Catch all cases where value is already the right typeif (c.isAssignableFrom(value.getClass())){
return value;}This is some kind of a optimization, right ? But as a side effectit makes it impossible to do any conversion on textfield inputif it is stored to String field in model (quite usual case, I think).
Maybe just drop those lines ?Ari S.- Original Message -From: Eelco Hillenius [EMAIL PROTECTED]To:
wicket-user@lists.sourceforge.netSent: Tuesday, March 07, 2006 7:22 PMSubject: Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
I don't think we need it in core. Maybe as an example somewhere. We have to get our users get used to working with custom components more, as that's one of the key points of Wicket imo :)
Eelco On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: but do we need this in core? its a trivial subclass, why not create it in
your own codebase? if you guys want it in core you can have it, just asking. -Igor On 3/7/06, Ryan Sonnek
[EMAIL PROTECTED] wrote: +1 for this solution.this seems to be the cleanest implementation to me and puts the responsibility on the developer to *use* the correct component.
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i guess thats true. you can create a subclass TrimmingTextField that
overrides getInput() and trims it. -Igor On 3/7/06, Johan Compagner
[EMAIL PROTECTED] wrote: So before the input goes into the required/type conversion and validators we first trim it
when that flag is set?. he also could just overwrite getInput() and trim the text when called.
johan
On 3/7/06, Igor Vaynberg [EMAIL PROTECTED] wrote: i was also thinking a trim flag on the textfield and textarea only.
are you opposed to that also Johan? -Igor
On 3/7/06, Johan Compagner [EMAIL PROTECTED] wrote:
You also could use a Converter for this i guess.johan
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi, But simple validation is already on wicket level. Of course we could argue on this, but I really think that right place for simple
input cleanup is the user interface layer: - Let's say I have a model, which has field called code.
- If user types new value for this in a field, I (and even user, I think) excepts that invisible blanks at end of code are removed. It
is very easy to accidentally put them there with copy paste, for example. - However, if I code something like this:
m.setCode(ZAP ); I sure except that it is stored excactly as I wrote. Besides, who it would harm if TextField TextArea had a flag
like this ? Nobody forces one to use it. Ari S.
- Original Message - From: Johan Compagner [EMAIL PROTECTED] To:
wicket-user@lists.sourceforge.net Sent: Tuesday, March 07, 2006 11:35 AM Subject: Re: [Wicket-user] TextField and trimming blanks at end
(and maybe at beginning) a trim flag on what? Form component?
I don't like that what does it do for non text fields? trimming should belong in a model. For example a ModelWrapper
where you put youre real models in. johan
On 3/7/06, Ari Suutari [EMAIL PROTECTED] wrote:
Hi, setTrimValue flag would be great (maybe there should be settings
for left/right trim ?). Model might be also a working solution, but somehow I feel
thatthis kind of task belongs to upper layer. Ari S.
- Original Message -From: Igor Vaynberg [EMAIL PROTECTED]
To: wicket-user@lists.sourceforge.net Sent: Monday, March 06, 2006 7:11 PM
Subject: Re: [Wicket-user] TextField and trimming blanks at end (and maybeat beginning)
this should be a flag on the textfield so you can callsetTrimValue(boolean)
what do others think? if not you can write a model that trims for you on setObject()
-Igor On 3/6/06, Ari Suutari
[EMAIL PROTECTED] wrote: Hi,
What might be the simplest way to change behaviour of whole wicket application so that TextField have their input trimmed of blanks at end
? I tried to do this via converters (I have my own converter
Re: [Wicket-user] TextField and trimming blanks at end (and maybe at beginning)
this should be a flag on the textfield so you can call setTrimValue(boolean) what do others think?if not you can write a model that trims for you on setObject()-Igor On 3/6/06, Ari Suutari [EMAIL PROTECTED] wrote: Hi,What might be the simplest way to change behaviour of whole wicket applicationso that TextField have their input trimmed of blanks at end ?I tried to do this via converters (I have my own converter factory), but it didn't work because Converter.convert doesn't do anythingif String is being assigned to String field in model (it uses isAssignableFromfor this check).Ari S.--- This SF.Net email is sponsored by xPML, a groundbreaking scripting languagethat extends applications into web and mobile media. Attend the live webcastand join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642___ Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
