Re: Uppercasing inputs
Sorry for a late response!! In this part of the world interest works 5-6 hours a day if you are fortunate and yesterday i was not... Man, It is my pleasure to be part of a project which made me most comfortable with j2ee ( I have worked from perl, php, python, asp to .NET, struts, spring MVC ). Hope I will be able to contribute to this project in a few months ... ( right now i am busy with two office projects ) Thanks everybody taha On Fri, Mar 6, 2009 at 8:11 PM, Leszek Gawron wrote: > taha siddiqi wrote: >> >> Thanks!!( everyone MADE a joke and I BECAME one ) > > I'm sorry if you felt offended. It wasn't personal. Maybe my expression was > not exact enough. After all I have used your proposal (modify Strings > directly in domain model). What I didn't like is the requirement to change > every set*( String value ) so I used AspectJ for that (which is probably a > total overkill). > > My regards > lg > -- > Leszek Gawron > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
taha siddiqi wrote: Thanks!!( everyone MADE a joke and I BECAME one ) I'm sorry if you felt offended. It wasn't personal. Maybe my expression was not exact enough. After all I have used your proposal (modify Strings directly in domain model). What I didn't like is the requirement to change every set*( String value ) so I used AspectJ for that (which is probably a total overkill). My regards lg -- Leszek Gawron - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Thanks!!( everyone MADE a joke and I BECAME one )
On Fri, Mar 6, 2009 at 3:55 PM, Leszek Gawron wrote:
> I've been out for one day. I come back and see a thread with 38 messages.
> That's crazy !:)
>
> jWeekend wrote:
>>
>> Leszek,
>>
>> Thank you asking such a deep question ;-)
>> We may not all agree, but in the end, at least you have been offered
>> around
>> 87 well-intentioned solutions you can ask your customer to choose from;
>> that
>> will teach them to request such complex features and fuctionality!
>
> I was really blown by the amount of approaches you all presented. Thank you
> for all of them.
>
> Some answers:
>
> 1. Dave wrote:
>>
>> A slightly different approach: I would talk with the customer again,
>> because this is a really stupid (excusez le mot) requirement. I hope you
>> understand their motivation, possibly some legacy system that depends on
>> uppercase information? Maybe the problem can be shifted to that legacy
>> system that uppercases all data read from the database?
>
> I thought so too but actually it's not that stupid after all. The customer
> has to enter A LOT of names, addresses etc. It speeds things up not to have
> to think about Proper Word Capitalization. Anything you type in always looks
> good.
>
> 2. I wanted to go with most non invasive way to do it. That is why I like:
>
>> public class UpperCaseBehavior extends AttributeAppender
>> {
>> private static final long serialVersionUID = 1L;
>>
>> public UpperCaseBehavior()
>> {
>> super("style", new Model("text-transform: uppercase"), ";");
>> }
>>
>> @Override
>> public void bind(Component component)
>> {
>> super.bind(component);
>> component.add(new AttributeAppender(
>> "onkeyup", new Model("this.value =
>> this.value.toUpperCase()"), ";"));
>> }
>> }
>>
>
> especially used with some nasty logic that would apply the behavior to every
> string field.
>
> This is why I find this:
>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>
> really ugly. Remember that I have to apply this for 99% of my domain model.
>
> 3. Igor, will this work:
>>
>> class uppercasetextfield extends textfield {
>> public void updatemodel()
>> {
>> final String str=getconvertedinput();
>> setdefaultmodelobject((str==null)?null:str.touppercase());
>> }
>> }
>
> If the form model is a loadable detachable model?
>
>
> The solution I chose:
>
>> @UpperCased
>> @Entity
>> @Table(name = "usr")
>> @Inheritance(strategy = InheritanceType.JOINED)
>> public class User extends Persistent {
>> private boolean active = true;
>> private String code;
>>
>> �...@normalcased
>> private String username;
>>
>> �...@normalcased
>> private String password;
>> private String firstName;
>> private String lastName;
>> private Set roles = new HashSet();
>> private String mobilePhone;
>> private String workPhone;
>> private String colour;
>
>> }
>
> and:
>
>> public aspect Uppercaser {
>> pointcut setString( String value ) : ( ( set(String (@UpperCased
>> *).* ) && set(!...@normalcased String *.* ) )
>>
>> || set(@UpperCased String *.* ) )
>>
>> && args( value );
>>
>> void around( String value ) : setString( value ) {
>> proceed( StringUtils.upperCase( value ) );
>> }
>> }
>
> because:
>
> 1. I decided that the uppercasing should available for junit tests/command
> line tools etc.
> 2. It introduces the least changes into existing code.
> 3. It allows me to get rid of uppercasing just by recompiling the domain
> model library without the aspect (if ever my customer came back to
> "sanity").
>
> It feels like I'm introducing way too complicated tool to solve an easy task
> (maybe judging by the number of the posts - not that easy after all), but
> what the hell...
>
>
> Thank you for all posts. You are by no means one of the most helpful and
> vigorous OS community there is.
>
> PS. I laughed almost to tears reading some posts. Very refreshing :)
>
> --
> Leszek Gawron 3.14159265358979323846264338327950288419716939937510
> 58209749445923078164062862089986280348253421170679
> 82148086513282306647093844609550582231725359408128
> 48111745028410270193852110555964462294895493038196
> 44288109756659334461284756482337867831652712019091
> 45648566923460348610454326648213393607260249141273
> 72458700660631558817488152092096282925409171536436
> 78925903600113305305488204665213841469519415116094
> 33057270365759591953092186117381932611793105118548
> 07446237996274956735188575272489122793818301194912
> 98336733624406566430860213949463952247371907021798
> 60943702770539217176293176752384674818467669405132
> 00056812714526356082778577134275778960917363717872
> 14684409012249534301465495853710507922796892589235
> 420199561121290219
Re: Uppercasing inputs
I've been out for one day. I come back and see a thread with 38
messages. That's crazy !:)
jWeekend wrote:
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered around
87 well-intentioned solutions you can ask your customer to choose from; that
will teach them to request such complex features and fuctionality!
I was really blown by the amount of approaches you all presented. Thank
you for all of them.
Some answers:
1. Dave wrote:
A slightly different approach: I would talk with the customer again, because
this is a really stupid (excusez le mot) requirement. I hope you understand
their motivation, possibly some legacy system that depends on uppercase
information? Maybe the problem can be shifted to that legacy system that
uppercases all data read from the database?
I thought so too but actually it's not that stupid after all. The
customer has to enter A LOT of names, addresses etc. It speeds things up
not to have to think about Proper Word Capitalization. Anything you type
in always looks good.
2. I wanted to go with most non invasive way to do it. That is why I like:
public class UpperCaseBehavior extends AttributeAppender
{
private static final long serialVersionUID = 1L;
public UpperCaseBehavior()
{
super("style", new Model("text-transform: uppercase"), ";");
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
"onkeyup", new Model("this.value = this.value.toUpperCase()"),
";"));
}
}
especially used with some nasty logic that would apply the behavior to
every string field.
This is why I find this:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
really ugly. Remember that I have to apply this for 99% of my domain model.
3. Igor, will this work:
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
If the form model is a loadable detachable model?
The solution I chose:
@UpperCased
@Entity
@Table(name = "usr")
@Inheritance(strategy = InheritanceType.JOINED)
public class User extends Persistent {
private boolean active = true;
private String code;
@NormalCased
private String username;
@NormalCased
private String password;
private String firstName;
private String lastName;
private Set roles = new HashSet();
private String mobilePhone;
private String workPhone;
private String colour;
> }
and:
public aspect Uppercaser {
pointcut setString( String value ) : ( ( set(String (@UpperCased *).* )
&& set(!...@normalcased String *.* ) )
|| set(@UpperCased String *.* ) )
&& args( value );
void around( String value ) : setString( value ) {
proceed( StringUtils.upperCase( value ) );
}
}
because:
1. I decided that the uppercasing should available for junit
tests/command line tools etc.
2. It introduces the least changes into existing code.
3. It allows me to get rid of uppercasing just by recompiling the domain
model library without the aspect (if ever my customer came back to
"sanity").
It feels like I'm introducing way too complicated tool to solve an easy
task (maybe judging by the number of the posts - not that easy after
all), but what the hell...
Thank you for all posts. You are by no means one of the most helpful and
vigorous OS community there is.
PS. I laughed almost to tears reading some posts. Very refreshing :)
--
Leszek Gawron 3.14159265358979323846264338327950288419716939937510
58209749445923078164062862089986280348253421170679
82148086513282306647093844609550582231725359408128
48111745028410270193852110555964462294895493038196
44288109756659334461284756482337867831652712019091
45648566923460348610454326648213393607260249141273
72458700660631558817488152092096282925409171536436
78925903600113305305488204665213841469519415116094
33057270365759591953092186117381932611793105118548
07446237996274956735188575272489122793818301194912
98336733624406566430860213949463952247371907021798
60943702770539217176293176752384674818467669405132
00056812714526356082778577134275778960917363717872
14684409012249534301465495853710507922796892589235
42019956112129021960864034418159813629774771309960
5187072113499837297804995105973173281609631859
50244594553469083026425223082533446850352619311881
71010003137838752886587533208381420617177669147303
59825349042875546873115956286388235378759375
Re: Uppercasing inputs
Igor, You made it very clear why a converter isn't appropriate. And also why you shouldn't use a Validator when you don't want to force the user to enter uppercase. But what's your opinion about using an UpperCasingModel ? Downside of overriding getInput is that you'd have to do it on TextField, PasswordTextFiled, RequiredTextField, AutoCompleteTextField, ... Or am I missing something ? Maarten On Thu, Mar 5, 2009 at 7:19 PM, Igor Vaynberg wrote: > if you want the users to have to enter the uppercase then use a > validator, if you want to uppercase for them then override getinput() > on the textfield and perform the uppercasing there. > > -igor > > On Thu, Mar 5, 2009 at 9:46 AM, Peter Ertl wrote: > > So what's the result o this? > > > > "My dear customer, actually it is not possible to upper-case your input > > because type conversion doesn't fit, validation is the wrong place,too, > and > > javascript uppercasing is not reliable if javascript is disabled. However > we > > can compute the 100.000.000 digit of pi but uppercase is too > complicated..." > > > > *g* > > > > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > > > >> > >> Igor, > >> > >>> anyways, just letting you know the intention behind the converters in > >>> wicket. > >> > >> OK - that's exactly the thing that needs to be crystal clear. > >> So the bottom line is that the if in your scenario the user entering > lower > >> case strings is acceptable then, in Wicket, the conversion to upper-case > >> is > >> not a job for IConverter and something downstream should take care of a > >> the > >> transformation to upper case (within Wicket or further down). > >> > >> If the user input should not even be submitted unless it is in upper > case, > >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html > >> Adriano's solution or something that has a similar effect. > >> > >> Is that summary correct? > >> > >> Regards - Cemal > >> http://jWeekend.om jWeekend > >> > >> > >> igor.vaynberg wrote: > >>> > >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend > >>> wrote: > >>>> > >>>> Igor, > >>>> > >>>> If there was a Java type called UpperCaseString that's what the > >>>> developer > >>>> would use as the underlying object and you would not have this > >>>> objection. > >>>> What's the difference between a converter translating 2009-04-04 to a > >>>> java.util.Date or even to a LunchDate which always sets the time part > to > >>>> midday? > >>> > >>> there isnt an UpperCaseString for a good reason :) if you went as far > >>> as creating an uppercasestring type, then i would say that it is a > >>> fair conversion. but then again, creating a type just to uppercase > >>> something seems broken, so its not a valid argument. > >>> > >>> if you had a lunchdate that sets the time to noon it would be a fair > >>> conversion because you would be converting the string date portion to > >>> a proper type. but then again, why would you have a lunchdate and not > >>> just use date if you already know the time is always noon? > >>> > >>> the point of converters is to take a type-agnostic input in a form of > >>> a string and convert it to a proper type. if your expected type is > >>> also a string then really no conversion should happen. there are > >>> *type* converters, thats is why they have tostring(object) and > >>> toobject(string), not a single object convert(object). anyways, just > >>> letting you know the intention behind the converters in wicket. i > >>> would say what you are doing is abusing the system and it is not > >>> guaranteed to keep working in 1.5. just my two cents. > >>> > >>>> I agree clearly that the translation should not be done by the > >>>> validator. > >>> > >>> my point was not that the conversion should not be done by the > >>> validator, my point was that the validator should not check the > >>> uppercase requirement. entering something in uppercase is not a > >>> requirement on the user its a requirement on the system that stores > >>> the input, validators deal with user-related requirements. &
Re: Uppercasing inputs
Could there be any unexpected consequences when just up-casing the
string in the model's setter (setObject(...)) ?
like this...
void setObject(String input)
{
this.value = (input != null) ? input.toUpperCase() : null;
}
Am 05.03.2009 um 19:39 schrieb jWeekend:
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered
around
87 well-intentioned solutions you can ask your customer to choose
from; that
will teach them to request such complex features and fuctionality!
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22357806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered around
87 well-intentioned solutions you can ask your customer to choose from; that
will teach them to request such complex features and fuctionality!
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
>
> Hello,
>
> one of my customers has this weird requirement that all data should be
> input/shown uppercase. I can easily add
>
> input {
>text-transform: uppercase;
> }
>
> to my css rules, but this does not change the fact that data written
> into database will still be case sensitive.
>
> How can I create a behavior for TextField so that the dat is uppercased
> before being written to the model?
>
> my regards
>
> --
> Leszek Gawron
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22357806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Due to the mind-boggling complexity of this issue I wrote an open source library 'upstring.jar' which provides plenty of useful stuff... example classes and methods... - class UpperCaseString - class LowerCaseString - class InitialUpperCaseWithRemainingLowerCaseString - class CamelCaseString - class UpperCaseAtPositionString(int firstIndex, int lastIndex) - UpperCaseDecorator(String original) - UpperCaseProvider.getUpperCaseInstance(Locale locale) - UpperCaseUtil.countUpperCaseChars(Object arg) Am 05.03.2009 um 19:01 schrieb jWeekend: Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: So what's the result o this? "My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated..." *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? there isnt an UpperCaseString for a good reason :) if you went as far as creating an uppercasestring type, then i would say that it is a fair conversion. but then again, creating a type just to uppercase something seems broken, so its not a valid argument. if you had a lunchdate that sets the time to noon it would be a fair conversion because you would be converting the string date portion to a proper type. but then again, why would you have a lunchdate and not just use date if you already know the time is always noon? the point of converters is to take a type-agnostic input in a form of a string and convert it to a proper type. if your expected type is also a string then really no conversion should happen. there are *type* converters, thats is why they have tostring(object) and toobject(string), not a single object convert(object). anyways, just letting you know the intention behind the converters in wicket. i would say what you are doing is abusing the system and it is not guaranteed to keep working in 1.5. just my two cents. I agree clearly that the translation should not be done by the validator. my point was not that the conversion should not be done by the validator, my point was that the validator should not check the uppercase requirement. entering something in uppercase is not a requirement on the user its a requirement on the system that stores the input, validators deal with user-related requirements. -igor Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: using conversion and validation for this is wrong. converters in wicket are meant to convert from type<->string because the web is type-agnostic. a string<->string conversion is not a conversion from wicket's point of view. yes, the code is somewhat unclear, we are going to address this in 1.5 where we can change some api and better name things. validation is also wrong. validation checks user input. the requirement to have this entered in uppercase is not on the user, it is on the system. so a validator should not fail because something was entered
Re: Uppercasing inputs
if you want the users to have to enter the uppercase then use a validator, if you want to uppercase for them then override getinput() on the textfield and perform the uppercasing there. -igor On Thu, Mar 5, 2009 at 9:46 AM, Peter Ertl wrote: > So what's the result o this? > > "My dear customer, actually it is not possible to upper-case your input > because type conversion doesn't fit, validation is the wrong place,too, and > javascript uppercasing is not reliable if javascript is disabled. However we > can compute the 100.000.000 digit of pi but uppercase is too complicated..." > > *g* > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > >> >> Igor, >> >>> anyways, just letting you know the intention behind the converters in >>> wicket. >> >> OK - that's exactly the thing that needs to be crystal clear. >> So the bottom line is that the if in your scenario the user entering lower >> case strings is acceptable then, in Wicket, the conversion to upper-case >> is >> not a job for IConverter and something downstream should take care of a >> the >> transformation to upper case (within Wicket or further down). >> >> If the user input should not even be submitted unless it is in upper case, >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html >> Adriano's solution or something that has a similar effect. >> >> Is that summary correct? >> >> Regards - Cemal >> http://jWeekend.om jWeekend >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend >>> wrote: >>>> >>>> Igor, >>>> >>>> If there was a Java type called UpperCaseString that's what the >>>> developer >>>> would use as the underlying object and you would not have this >>>> objection. >>>> What's the difference between a converter translating 2009-04-04 to a >>>> java.util.Date or even to a LunchDate which always sets the time part to >>>> midday? >>> >>> there isnt an UpperCaseString for a good reason :) if you went as far >>> as creating an uppercasestring type, then i would say that it is a >>> fair conversion. but then again, creating a type just to uppercase >>> something seems broken, so its not a valid argument. >>> >>> if you had a lunchdate that sets the time to noon it would be a fair >>> conversion because you would be converting the string date portion to >>> a proper type. but then again, why would you have a lunchdate and not >>> just use date if you already know the time is always noon? >>> >>> the point of converters is to take a type-agnostic input in a form of >>> a string and convert it to a proper type. if your expected type is >>> also a string then really no conversion should happen. there are >>> *type* converters, thats is why they have tostring(object) and >>> toobject(string), not a single object convert(object). anyways, just >>> letting you know the intention behind the converters in wicket. i >>> would say what you are doing is abusing the system and it is not >>> guaranteed to keep working in 1.5. just my two cents. >>> >>>> I agree clearly that the translation should not be done by the >>>> validator. >>> >>> my point was not that the conversion should not be done by the >>> validator, my point was that the validator should not check the >>> uppercase requirement. entering something in uppercase is not a >>> requirement on the user its a requirement on the system that stores >>> the input, validators deal with user-related requirements. >>> >>> -igor >>> >>>> >>>> Regards - Cemal >>>> http;//jWeekend.com >>>> >>>> >>>> igor.vaynberg wrote: >>>>> >>>>> using conversion and validation for this is wrong. >>>>> >>>>> converters in wicket are meant to convert from type<->string because >>>>> the web is type-agnostic. a string<->string conversion is not a >>>>> conversion from wicket's point of view. yes, the code is somewhat >>>>> unclear, we are going to address this in 1.5 where we can change some >>>>> api and better name things. >>>>> >>>>> validation is also wrong. validation checks user input. the >>>>> requirement to have this entered in uppercase is not on the user, it &
Re: Uppercasing inputs
Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: > > So what's the result o this? > > "My dear customer, actually it is not possible to upper-case your > input because type conversion doesn't fit, validation is the wrong > place,too, and javascript uppercasing is not reliable if javascript is > disabled. However we can compute the 100.000.000 digit of pi but > uppercase is too complicated..." > > *g* > > > Am 05.03.2009 um 17:46 schrieb jWeekend: > >> >> Igor, >> >>> anyways, just letting you know the intention behind the converters in >>> wicket. >> >> OK - that's exactly the thing that needs to be crystal clear. >> So the bottom line is that the if in your scenario the user entering >> lower >> case strings is acceptable then, in Wicket, the conversion to upper- >> case is >> not a job for IConverter and something downstream should take care >> of a the >> transformation to upper case (within Wicket or further down). >> >> If the user input should not even be submitted unless it is in upper >> case, >> then use http://www.nabble.com/Re%3A-Uppercasing-inputs- >> p22332471.html >> Adriano's solution or something that has a similar effect. >> >> Is that summary correct? >> >> Regards - Cemal >> http://jWeekend.om jWeekend >> >> >> igor.vaynberg wrote: >>> >>> On Thu, Mar 5, 2009 at 8:12 AM, jWeekend >>> >>> wrote: >>>> >>>> Igor, >>>> >>>> If there was a Java type called UpperCaseString that's what the >>>> developer >>>> would use as the underlying object and you would not have this >>>> objection. >>>> What's the difference between a converter translating 2009-04-04 >>>> to a >>>> java.util.Date or even to a LunchDate which always sets the time >>>> part to >>>> midday? >>> >>> there isnt an UpperCaseString for a good reason :) if you went as far >>> as creating an uppercasestring type, then i would say that it is a >>> fair conversion. but then again, creating a type just to uppercase >>> something seems broken, so its not a valid argument. >>> >>> if you had a lunchdate that sets the time to noon it would be a fair >>> conversion because you would be converting the string date portion to >>> a proper type. but then again, why would you have a lunchdate and not >>> just use date if you already know the time is always noon? >>> >>> the point of converters is to take a type-agnostic input in a form of >>> a string and convert it to a proper type. if your expected type is >>> also a string then really no conversion should happen. there are >>> *type* converters, thats is why they have tostring(object) and >>> toobject(string), not a single object convert(object). anyways, just >>> letting you know the intention behind the converters in wicket. i >>> would say what you are doing is abusing the system and it is not >>> guaranteed to keep working in 1.5. just my two cents. >>> >>>> I agree clearly that the translation should not be done by the >>>> validator. >>> >>> my point was not that the conversion should not be done by the >>> validator, my point was that the validator should not check the >>> uppercase requirement. entering something in uppercase is not a >>> requirement on the user its a requirement on the system that stores >>> the input, validators deal with user-related requirements. >>> >>> -igor >>> >>>> >>>> Regards - Cemal >>>> http;//jWeekend.com >>>> >>>> >>>> igor.vaynberg wrote: >>>>> >>>>> using conversion and validation for this is wro
Re: Uppercasing inputs
So what's the result o this? "My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated..." *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend wrote: Igor, If there was a Java type called UpperCaseString that's what the developer would use as the underlying object and you would not have this objection. What's the difference between a converter translating 2009-04-04 to a java.util.Date or even to a LunchDate which always sets the time part to midday? there isnt an UpperCaseString for a good reason :) if you went as far as creating an uppercasestring type, then i would say that it is a fair conversion. but then again, creating a type just to uppercase something seems broken, so its not a valid argument. if you had a lunchdate that sets the time to noon it would be a fair conversion because you would be converting the string date portion to a proper type. but then again, why would you have a lunchdate and not just use date if you already know the time is always noon? the point of converters is to take a type-agnostic input in a form of a string and convert it to a proper type. if your expected type is also a string then really no conversion should happen. there are *type* converters, thats is why they have tostring(object) and toobject(string), not a single object convert(object). anyways, just letting you know the intention behind the converters in wicket. i would say what you are doing is abusing the system and it is not guaranteed to keep working in 1.5. just my two cents. I agree clearly that the translation should not be done by the validator. my point was not that the conversion should not be done by the validator, my point was that the validator should not check the uppercase requirement. entering something in uppercase is not a requirement on the user its a requirement on the system that stores the input, validators deal with user-related requirements. -igor Regards - Cemal http;//jWeekend.com igor.vaynberg wrote: using conversion and validation for this is wrong. converters in wicket are meant to convert from type<->string because the web is type-agnostic. a string<->string conversion is not a conversion from wicket's point of view. yes, the code is somewhat unclear, we are going to address this in 1.5 where we can change some api and better name things. validation is also wrong. validation checks user input. the requirement to have this entered in uppercase is not on the user, it is on the system. so a validator should not fail because something was entered in non-uppercase. -igor On Thu, Mar 5, 2009 at 1:26 AM, jWeekend > wrote: Martijn, Is there not already an EasyUpperCaseRUs.com web service you can subscribe to for unlimited conversions at an annual fee of under 30,000USD (or 100USD/conversion) who also have a "5 free conversions" trial subscription? Ether way, I would suggest this be done at conversion time so validation can do its job properly and you're not handing off conversion responsibilities where they don't belong. Some solutions leaving this transformation of the text input by the user until after conversion in the form processing life-cycle may be less lines of code (or less classes), but IMO, are bending rules and ignoring good design principles. Of course, others may disagree and come up with all sorts of "neat" solutions that still manage to upper-case a string; how about "just cut out the middle-man altogether and do it in a stored-procedure triggered on INSERT and UPDATE" - that would work too, but wouldn't be my choice. There's also a degree of "it depends" here, but generally, the form-processing life-cycle should be respected or explicitly overridden for a good design reason (to meet user requirements). Regards - Cemal http://jWeekend.com jWeekend M
Re: Uppercasing inputs
Igor, > anyways, just letting you know the intention behind the converters in > wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper-case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: > > On Thu, Mar 5, 2009 at 8:12 AM, jWeekend > wrote: >> >> Igor, >> >> If there was a Java type called UpperCaseString that's what the developer >> would use as the underlying object and you would not have this objection. >> What's the difference between a converter translating 2009-04-04 to a >> java.util.Date or even to a LunchDate which always sets the time part to >> midday? > > there isnt an UpperCaseString for a good reason :) if you went as far > as creating an uppercasestring type, then i would say that it is a > fair conversion. but then again, creating a type just to uppercase > something seems broken, so its not a valid argument. > > if you had a lunchdate that sets the time to noon it would be a fair > conversion because you would be converting the string date portion to > a proper type. but then again, why would you have a lunchdate and not > just use date if you already know the time is always noon? > > the point of converters is to take a type-agnostic input in a form of > a string and convert it to a proper type. if your expected type is > also a string then really no conversion should happen. there are > *type* converters, thats is why they have tostring(object) and > toobject(string), not a single object convert(object). anyways, just > letting you know the intention behind the converters in wicket. i > would say what you are doing is abusing the system and it is not > guaranteed to keep working in 1.5. just my two cents. > >> I agree clearly that the translation should not be done by the validator. > > my point was not that the conversion should not be done by the > validator, my point was that the validator should not check the > uppercase requirement. entering something in uppercase is not a > requirement on the user its a requirement on the system that stores > the input, validators deal with user-related requirements. > > -igor > >> >> Regards - Cemal >> http;//jWeekend.com >> >> >> igor.vaynberg wrote: >>> >>> using conversion and validation for this is wrong. >>> >>> converters in wicket are meant to convert from type<->string because >>> the web is type-agnostic. a string<->string conversion is not a >>> conversion from wicket's point of view. yes, the code is somewhat >>> unclear, we are going to address this in 1.5 where we can change some >>> api and better name things. >>> >>> validation is also wrong. validation checks user input. the >>> requirement to have this entered in uppercase is not on the user, it >>> is on the system. so a validator should not fail because something was >>> entered in non-uppercase. >>> >>> -igor >>> >>> >>> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend >>> wrote: >>>> >>>> Martijn, >>>> >>>> Is there not already an EasyUpperCaseRUs.com web service you can >>>> subscribe >>>> to for unlimited conversions at an annual fee of under 30,000USD (or >>>> 100USD/conversion) who also have a "5 free conversions" trial >>>> subscription? >>>> >>>> Ether way, I would suggest this be done at conversion time so >>>> validation >>>> can >>>> do its job properly and you're not handing off conversion >>>> responsibilities >>>> where they don't belong. Some solutions leaving this transformation of >>>> the >>>> text input by the user until after conversion in the form processing >>>> life-cycle may be less lines of code (or less classes), but IMO, are >>>> bending >>>> rules and ignoring good design principles. >>>> >>>> Of course, others may disagree and come up with all sorts of "neat" >>>> solutions that still manage to upper-c
Re: Uppercasing inputs
nd uses that to convert the values, then you can subclass textfield,
>>>>> override initmodel() and wrap any model the textfield had with this
>>>>> one.
>>>>>
>>>>> that way everyone is happy!
>>>>>
>>>>> -igor
>>>>>
>>>>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>>>>> wrote:
>>>>>> LOL! Nah - I would just change all the setters on every domain object
>>>>>> to
>>>>>> be:
>>>>>>
>>>>>> public void setFoo(String foo) {
>>>>>> this.foo = foo == null ? null : foo.toUpperCase();
>>>>>> }
>>>>>>
>>>>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>>>>> intercept
>>>>>> calls to com.mydomain setters that take a single string argument and
>>>>>> do
>>>>>> the
>>>>>> upper-casing there!
>>>>>>
>>>>>> It's makes me smile to think of how many ways a single thing can be
>>>>>> done.
>>>>>>
>>>>>> Leszek - you should now definitely have plenty of choices. Pick which
>>>>>> feels
>>>>>> best / most comfortable for you!
>>>>>>
>>>>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Igor,
>>>>>>>
>>>>>>> Nope, not for me (this time).
>>>>>>> Here's the Javadoc for updateModel:
>>>>>>> * Updates this components model from the request, it expects
>>>>>>> that
>>>>>>> the
>>>>>>> object is already
>>>>>>> * converted through the convertInput() call that is called by
>>>>>>> the
>>>>>>> validate() method when a form
>>>>>>> * is being processed.
>>>>>>>
>>>>>>> Regards - Cemal
>>>>>>> http://jWeekend.com jWeekend
>>>>>>>
>>>>>>>
>>>>>>> igor.vaynberg wrote:
>>>>>>> >
>>>>>>> > pft, you guys!
>>>>>>> >
>>>>>>> > i would go with the simplest!
>>>>>>> >
>>>>>>> > class uppercasetextfield extends textfield {
>>>>>>> > public void updatemodel()
>>>>>>> > {
>>>>>>> > final String str=getconvertedinput();
>>>>>>> >
>>>>>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>>>>>> > }
>>>>>>> > }
>>>>>>> >
>>>>>>> > done!
>>>>>>> >
>>>>>>> > -igor
>>>>>>> >
>>>>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>>>>>>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Jeremy,
>>>>>>> >>
>>>>>>> >> I sensed you were uncomfortable with my "most Wicket-way"
>>>>>>> suggestion
>>>>>>> when
>>>>>>> >> I
>>>>>>> >> read
>>>>>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>>>>>> >> previous post on this thread stating that the model doing the
>>>>>>> >> transformation work was on the "right track"; it is not unusual
>>>>>>> that
>>>>>>> more
>>>>>>> >> than one design can satisfy a given requirement.
>>>>>>> >>
>>>>>>> >> Do you like the idea of a model being responsible for conversion
>>>>>>> of
>>>>>>> >> users'
>>>>>>> >> textual input?
>>>>>>> >>
>>>>>>> >> Your article illustrates the use of nested models nicely but on
>>>>>>> this
>>>>>>> >> occasion I would probably go with
>>>>>>> >> http://www.nabble.com/Re%3A
Re: Uppercasing inputs
m.mydomain setters that take a single string argument and
>>>>>> do
>>>>>> the
>>>>>> upper-casing there!
>>>>>>
>>>>>> It's makes me smile to think of how many ways a single thing can be
>>>>>> done.
>>>>>>
>>>>>> Leszek - you should now definitely have plenty of choices. Pick which
>>>>>> feels
>>>>>> best / most comfortable for you!
>>>>>>
>>>>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Igor,
>>>>>>>
>>>>>>> Nope, not for me (this time).
>>>>>>> Here's the Javadoc for updateModel:
>>>>>>> * Updates this components model from the request, it expects
>>>>>>> that
>>>>>>> the
>>>>>>> object is already
>>>>>>> * converted through the convertInput() call that is called by
>>>>>>> the
>>>>>>> validate() method when a form
>>>>>>> * is being processed.
>>>>>>>
>>>>>>> Regards - Cemal
>>>>>>> http://jWeekend.com jWeekend
>>>>>>>
>>>>>>>
>>>>>>> igor.vaynberg wrote:
>>>>>>> >
>>>>>>> > pft, you guys!
>>>>>>> >
>>>>>>> > i would go with the simplest!
>>>>>>> >
>>>>>>> > class uppercasetextfield extends textfield {
>>>>>>> > public void updatemodel()
>>>>>>> > {
>>>>>>> > final String str=getconvertedinput();
>>>>>>> >
>>>>>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>>>>>> > }
>>>>>>> > }
>>>>>>> >
>>>>>>> > done!
>>>>>>> >
>>>>>>> > -igor
>>>>>>> >
>>>>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>>>>>>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Jeremy,
>>>>>>> >>
>>>>>>> >> I sensed you were uncomfortable with my "most Wicket-way"
>>>>>>> suggestion
>>>>>>> when
>>>>>>> >> I
>>>>>>> >> read
>>>>>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>>>>>> >> previous post on this thread stating that the model doing the
>>>>>>> >> transformation work was on the "right track"; it is not unusual
>>>>>>> that
>>>>>>> more
>>>>>>> >> than one design can satisfy a given requirement.
>>>>>>> >>
>>>>>>> >> Do you like the idea of a model being responsible for conversion
>>>>>>> of
>>>>>>> >> users'
>>>>>>> >> textual input?
>>>>>>> >>
>>>>>>> >> Your article illustrates the use of nested models nicely but on
>>>>>>> this
>>>>>>> >> occasion I would probably go with
>>>>>>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
>>>>>>> Adriano's
>>>>>>> >> idea
>>>>>>> >> for a client side, instant gratification, solution, and a custom
>>>>>>> text
>>>>>>> >> field
>>>>>>> >> with a converter if the conversion can happen later, on the
>>>>>>> server.
>>>>>>> >>
>>>>>>> >> Regards - Cemal
>>>>>>> >> http://jWeekend.com jWeekend
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Jeremy Thomerson-5 wrote:
>>>>>>> >>>
>>>>>>> >>> Cemal,
>>>>>>> >>> I think I have to respectfully disagree w
Re: Uppercasing inputs
Igor,
If there was a Java type called UpperCaseString that's what the developer
would use as the underlying object and you would not have this objection.
What's the difference between a converter translating 2009-04-04 to a
java.util.Date or even to a LunchDate which always sets the time part to
midday?
I agree clearly that the translation should not be done by the validator.
Regards - Cemal
http;//jWeekend.com
igor.vaynberg wrote:
>
> using conversion and validation for this is wrong.
>
> converters in wicket are meant to convert from type<->string because
> the web is type-agnostic. a string<->string conversion is not a
> conversion from wicket's point of view. yes, the code is somewhat
> unclear, we are going to address this in 1.5 where we can change some
> api and better name things.
>
> validation is also wrong. validation checks user input. the
> requirement to have this entered in uppercase is not on the user, it
> is on the system. so a validator should not fail because something was
> entered in non-uppercase.
>
> -igor
>
>
> On Thu, Mar 5, 2009 at 1:26 AM, jWeekend
> wrote:
>>
>> Martijn,
>>
>> Is there not already an EasyUpperCaseRUs.com web service you can
>> subscribe
>> to for unlimited conversions at an annual fee of under 30,000USD (or
>> 100USD/conversion) who also have a "5 free conversions" trial
>> subscription?
>>
>> Ether way, I would suggest this be done at conversion time so validation
>> can
>> do its job properly and you're not handing off conversion
>> responsibilities
>> where they don't belong. Some solutions leaving this transformation of
>> the
>> text input by the user until after conversion in the form processing
>> life-cycle may be less lines of code (or less classes), but IMO, are
>> bending
>> rules and ignoring good design principles.
>>
>> Of course, others may disagree and come up with all sorts of "neat"
>> solutions that still manage to upper-case a string; how about "just cut
>> out
>> the middle-man altogether and do it in a stored-procedure triggered on
>> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>>
>> There's also a degree of "it depends" here, but generally, the
>> form-processing life-cycle should be respected or explicitly overridden
>> for
>> a good design reason (to meet user requirements).
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>> Martijn Dashorst wrote:
>>>
>>> I suggest setting up an ESB with a UppercaseService that is available
>>> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
>>> that UppercaseService to make the value uppercase.
>>>
>>> Martijn
>>>
>>> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
>>> wrote:
>>>> you can create a convertermodel that takes an instance of iconverter
>>>> and uses that to convert the values, then you can subclass textfield,
>>>> override initmodel() and wrap any model the textfield had with this
>>>> one.
>>>>
>>>> that way everyone is happy!
>>>>
>>>> -igor
>>>>
>>>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>>>> wrote:
>>>>> LOL! Nah - I would just change all the setters on every domain object
>>>>> to
>>>>> be:
>>>>>
>>>>> public void setFoo(String foo) {
>>>>> this.foo = foo == null ? null : foo.toUpperCase();
>>>>> }
>>>>>
>>>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>>>> intercept
>>>>> calls to com.mydomain setters that take a single string argument and
>>>>> do
>>>>> the
>>>>> upper-casing there!
>>>>>
>>>>> It's makes me smile to think of how many ways a single thing can be
>>>>> done.
>>>>>
>>>>> Leszek - you should now definitely have plenty of choices. Pick which
>>>>> feels
>>>>> best / most comfortable for you!
>>>>>
>>>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Igor,
>>>>>>
>>>>>> Nope, not for me (this time).
>>>>>> Here's the Javadoc for updateModel:
>>>>>> * Updates this component
Re: Uppercasing inputs
using conversion and validation for this is wrong.
converters in wicket are meant to convert from type<->string because
the web is type-agnostic. a string<->string conversion is not a
conversion from wicket's point of view. yes, the code is somewhat
unclear, we are going to address this in 1.5 where we can change some
api and better name things.
validation is also wrong. validation checks user input. the
requirement to have this entered in uppercase is not on the user, it
is on the system. so a validator should not fail because something was
entered in non-uppercase.
-igor
On Thu, Mar 5, 2009 at 1:26 AM, jWeekend wrote:
>
> Martijn,
>
> Is there not already an EasyUpperCaseRUs.com web service you can subscribe
> to for unlimited conversions at an annual fee of under 30,000USD (or
> 100USD/conversion) who also have a "5 free conversions" trial subscription?
>
> Ether way, I would suggest this be done at conversion time so validation can
> do its job properly and you're not handing off conversion responsibilities
> where they don't belong. Some solutions leaving this transformation of the
> text input by the user until after conversion in the form processing
> life-cycle may be less lines of code (or less classes), but IMO, are bending
> rules and ignoring good design principles.
>
> Of course, others may disagree and come up with all sorts of "neat"
> solutions that still manage to upper-case a string; how about "just cut out
> the middle-man altogether and do it in a stored-procedure triggered on
> INSERT and UPDATE" - that would work too, but wouldn't be my choice.
>
> There's also a degree of "it depends" here, but generally, the
> form-processing life-cycle should be respected or explicitly overridden for
> a good design reason (to meet user requirements).
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> Martijn Dashorst wrote:
>>
>> I suggest setting up an ESB with a UppercaseService that is available
>> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
>> that UppercaseService to make the value uppercase.
>>
>> Martijn
>>
>> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
>> wrote:
>>> you can create a convertermodel that takes an instance of iconverter
>>> and uses that to convert the values, then you can subclass textfield,
>>> override initmodel() and wrap any model the textfield had with this
>>> one.
>>>
>>> that way everyone is happy!
>>>
>>> -igor
>>>
>>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>>> wrote:
>>>> LOL! Nah - I would just change all the setters on every domain object
>>>> to
>>>> be:
>>>>
>>>> public void setFoo(String foo) {
>>>> this.foo = foo == null ? null : foo.toUpperCase();
>>>> }
>>>>
>>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>>> intercept
>>>> calls to com.mydomain setters that take a single string argument and do
>>>> the
>>>> upper-casing there!
>>>>
>>>> It's makes me smile to think of how many ways a single thing can be
>>>> done.
>>>>
>>>> Leszek - you should now definitely have plenty of choices. Pick which
>>>> feels
>>>> best / most comfortable for you!
>>>>
>>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>>> wrote:
>>>>
>>>>>
>>>>> Igor,
>>>>>
>>>>> Nope, not for me (this time).
>>>>> Here's the Javadoc for updateModel:
>>>>> * Updates this components model from the request, it expects
>>>>> that
>>>>> the
>>>>> object is already
>>>>> * converted through the convertInput() call that is called by
>>>>> the
>>>>> validate() method when a form
>>>>> * is being processed.
>>>>>
>>>>> Regards - Cemal
>>>>> http://jWeekend.com jWeekend
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>> >
>>>>> > pft, you guys!
>>>>> >
>>>>> > i would go with the simplest!
>>>>> >
>>>>> > class uppercasetextfield extends textfield {
>>>>> > public void updatemodel()
>>>>> > {
>>>>> > final String str=getconverted
Re: Uppercasing inputs
Yes, I love that mailing list :-)
Am 05.03.2009 um 10:26 schrieb jWeekend:
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can
subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a "5 free conversions" trial
subscription?
Ether way, I would suggest this be done at conversion time so
validation can
do its job properly and you're not handing off conversion
responsibilities
where they don't belong. Some solutions leaving this transformation
of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are
bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of "neat"
solutions that still manage to upper-case a string; how about "just
cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE" - that would work too, but wouldn't be my choice.
There's also a degree of "it depends" here, but generally, the
form-processing life-cycle should be respected or explicitly
overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg >
wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass
textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
LOL! Nah - I would just change all the setters on every domain
object
to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically
intercept
calls to com.mydomain setters that take a single string argument
and do
the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be
done.
Leszek - you should now definitely have plenty of choices. Pick
which
feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
wrote:
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it
expects
that
the
object is already
* converted through the convertInput() call that is
called by
the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
wrote:
Jeremy,
I sensed you were uncomfortable with my "most Wicket-way"
suggestion
when
I
read
http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
previous post on this thread stating that the model doing the
transformation work was on the "right track"; it is not
unusual that
more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for
conversion of
users'
textual input?
Your article illustrates the use of nested models nicely but
on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
Adriano's
idea
for a client side, instant gratification, solution, and a custom
text
field
with a converter if the conversion can happen later, on the
server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
Cemal,
I think I have to respectfully disagree with you here. I
describe
what
I
feel is a better solution, and a little bit of why in this blog
post
from
a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable
across
many
components - you have to create overridden variants of each
type of
input.
Also, a converter (or more specifically, an implementation of
IConverter)
is
supposed to be for transforming a type of object to a string
usable
in
the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes "there are many ways to skin a
cat" -
although
the saying isn't that great, I think it applies - there are
multiple
ways
of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.w
Re: Uppercasing inputs
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a "5 free conversions" trial subscription?
Ether way, I would suggest this be done at conversion time so validation can
do its job properly and you're not handing off conversion responsibilities
where they don't belong. Some solutions leaving this transformation of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of "neat"
solutions that still manage to upper-case a string; how about "just cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE" - that would work too, but wouldn't be my choice.
There's also a degree of "it depends" here, but generally, the
form-processing life-cycle should be respected or explicitly overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
>
> I suggest setting up an ESB with a UppercaseService that is available
> through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
> that UppercaseService to make the value uppercase.
>
> Martijn
>
> On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg
> wrote:
>> you can create a convertermodel that takes an instance of iconverter
>> and uses that to convert the values, then you can subclass textfield,
>> override initmodel() and wrap any model the textfield had with this
>> one.
>>
>> that way everyone is happy!
>>
>> -igor
>>
>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>> wrote:
>>> LOL! Nah - I would just change all the setters on every domain object
>>> to
>>> be:
>>>
>>> public void setFoo(String foo) {
>>> this.foo = foo == null ? null : foo.toUpperCase();
>>> }
>>>
>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>> intercept
>>> calls to com.mydomain setters that take a single string argument and do
>>> the
>>> upper-casing there!
>>>
>>> It's makes me smile to think of how many ways a single thing can be
>>> done.
>>>
>>> Leszek - you should now definitely have plenty of choices. Pick which
>>> feels
>>> best / most comfortable for you!
>>>
>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>> wrote:
>>>
>>>>
>>>> Igor,
>>>>
>>>> Nope, not for me (this time).
>>>> Here's the Javadoc for updateModel:
>>>> * Updates this components model from the request, it expects
>>>> that
>>>> the
>>>> object is already
>>>> * converted through the convertInput() call that is called by
>>>> the
>>>> validate() method when a form
>>>> * is being processed.
>>>>
>>>> Regards - Cemal
>>>> http://jWeekend.com jWeekend
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>> >
>>>> > pft, you guys!
>>>> >
>>>> > i would go with the simplest!
>>>> >
>>>> > class uppercasetextfield extends textfield {
>>>> > public void updatemodel()
>>>> > {
>>>> > final String str=getconvertedinput();
>>>> >
>>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>>> > }
>>>> > }
>>>> >
>>>> > done!
>>>> >
>>>> > -igor
>>>> >
>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>>>
>>>> > wrote:
>>>> >>
>>>> >> Jeremy,
>>>> >>
>>>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>>>> when
>>>> >> I
>>>> >> read
>>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>>> >> previous post on this thread stating that the model doing the
>>>> >> transformation work was on the "right track"; it is not unusual that
>>>> more
>>>> >> than one design can satisfy a given requirement.
>>>> >>
Re: Uppercasing inputs
LOL! That sounds scalable!
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg wrote:
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
LOL! Nah - I would just change all the setters on every domain object to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically intercept
calls to com.mydomain setters that take a single string argument and do the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be done.
Leszek - you should now definitely have plenty of choices. Pick which feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it expects that
the
object is already
* converted through the convertInput() call that is called by the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
wrote:
Jeremy,
I sensed you were uncomfortable with my "most Wicket-way" suggestion
when
I
read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
previous post on this thread stating that the model doing the
transformation work was on the "right track"; it is not unusual that
more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for conversion of
users'
textual input?
Your article illustrates the use of nested models nicely but on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
idea
for a client side, instant gratification, solution, and a custom text
field
with a converter if the conversion can happen later, on the server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
Cemal,
I think I have to respectfully disagree with you here. I describe
what
I
feel is a better solution, and a little bit of why in this blog post
from
a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable across many
components - you have to create overridden variants of each type of
input.
Also, a converter (or more specifically, an implementation of
IConverter)
is
supposed to be for transforming a type of object to a string usable in
the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes "there are many ways to skin a cat" -
although
the saying isn't that great, I think it applies - there are multiple
ways
of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
wrote:
Leszek,
... or, probably the most "Wicket-way" of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332
Re: Uppercasing inputs
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg wrote:
> you can create a convertermodel that takes an instance of iconverter
> and uses that to convert the values, then you can subclass textfield,
> override initmodel() and wrap any model the textfield had with this
> one.
>
> that way everyone is happy!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically intercept
>> calls to com.mydomain setters that take a single string argument and do the
>> upper-casing there!
>>
>> It's makes me smile to think of how many ways a single thing can be done.
>>
>> Leszek - you should now definitely have plenty of choices. Pick which feels
>> best / most comfortable for you!
>>
>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
>>
>>>
>>> Igor,
>>>
>>> Nope, not for me (this time).
>>> Here's the Javadoc for updateModel:
>>> * Updates this components model from the request, it expects that
>>> the
>>> object is already
>>> * converted through the convertInput() call that is called by the
>>> validate() method when a form
>>> * is being processed.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> igor.vaynberg wrote:
>>> >
>>> > pft, you guys!
>>> >
>>> > i would go with the simplest!
>>> >
>>> > class uppercasetextfield extends textfield {
>>> > public void updatemodel()
>>> > {
>>> > final String str=getconvertedinput();
>>> > setdefaultmodelobject((str==null)?null:str.touppercase());
>>> > }
>>> > }
>>> >
>>> > done!
>>> >
>>> > -igor
>>> >
>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>> > wrote:
>>> >>
>>> >> Jeremy,
>>> >>
>>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>>> when
>>> >> I
>>> >> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>> >> previous post on this thread stating that the model doing the
>>> >> transformation work was on the "right track"; it is not unusual that
>>> more
>>> >> than one design can satisfy a given requirement.
>>> >>
>>> >> Do you like the idea of a model being responsible for conversion of
>>> >> users'
>>> >> textual input?
>>> >>
>>> >> Your article illustrates the use of nested models nicely but on this
>>> >> occasion I would probably go with
>>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
>>> >> idea
>>> >> for a client side, instant gratification, solution, and a custom text
>>> >> field
>>> >> with a converter if the conversion can happen later, on the server.
>>> >>
>>> >> Regards - Cemal
>>> >> http://jWeekend.com jWeekend
>>> >>
>>> >>
>>> >>
>>> >> Jeremy Thomerson-5 wrote:
>>> >>>
>>> >>> Cemal,
>>> >>> I think I have to respectfully disagree with you here. I describe
>>> >>> what
>>> >>> I
>>> >>> feel is a better solution, and a little bit of why in this blog post
>>> >>> from
>>> >>> a
>>> >>> few months ago:
>>> >>>
>>> >>>
>>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>> >>>
>>> >>> Basically, doing it the way you suggested isn't reusable across many
>>> >>> components - you have to create overridden variants of each type of
>>> >>> input.
>>> >>> Also, a converter (or
Re: Uppercasing inputs
Hi Jeremy,
Nice post! I'll think I'll start using that approach myself more
frequently.
Best,
Ernesto
On Wed, Mar 4, 2009 at 9:19 PM, Jeremy Thomerson
wrote:
> Ernesto's got you on the right track. I'd recommend taking it a step
> further like described here:
>
>
> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>
>
> Jeremy Thomerson
> http://www.wickettraining.com
> -- sent from a wireless device
>
>
> -Original Message-
> From: Ernesto Reinaldo Barreiro
> Sent: Wednesday, March 04, 2009 9:43 AM
> To: users@wicket.apache.org
> Subject: Re: Uppercasing inputs
>
> Maybe:
>
> class MyUpperCaseModel extends WhatEverModel {
>
>
> public void setObject(String value) {
> if(value != null) {
> super.setValue(value.toUpperCase());
> } else {
> super.setValue(value);
> }
> }
>
>
> }
>
> and use MyUpperCaseModel instead of WhatEverModel.
>
> Ernesto
>
> - Show quoted text -
> On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron wrote:
>
> > Hello,
> >
> > one of my customers has this weird requirement that all data should be
> > input/shown uppercase. I can easily add
> >
> > input {
> > text-transform: uppercase;
> > }
> >
> > to my css rules, but this does not change the fact that data written into
> > database will still be case sensitive.
> >
> > How can I create a behavior for TextField so that the dat is uppercased
> > before being written to the model?
> >
> > my regards
> >
> > --
> > Leszek Gawron
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Uppercasing inputs
Argh.. and ofcourse, you can uppercase it in your model get/set method.
**
Martin
2009/3/5 Martin Makundi :
> It should also be easy to either
> a) uppercase the data using your own converter or
> b) uppercasing it before persisting
>
> **
> Martin
>
> 2009/3/5 Dave Schoorl :
> - Näytä lainattu teksti -
>> A slightly different approach: I would talk with the customer again, because
>> this is a really stupid (excusez le mot) requirement. I hope you understand
>> their motivation, possibly some legacy system that depends on uppercase
>> information? Maybe the problem can be shifted to that legacy system that
>> uppercases all data read from the database?
>>
>> Regards,
>> Dave
>>
>>
>> Leszek Gawron wrote:
>>>
>>> Hello,
>>>
>>> one of my customers has this weird requirement that all data should be
>>> input/shown uppercase. I can easily add
>>>
>>> input {
>>> text-transform: uppercase;
>>> }
>>>
>>> to my css rules, but this does not change the fact that data written into
>>> database will still be case sensitive.
>>>
>>> How can I create a behavior for TextField so that the dat is uppercased
>>> before being written to the model?
>>>
>>> my regards
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
It should also be easy to either
a) uppercase the data using your own converter or
b) uppercasing it before persisting
**
Martin
2009/3/5 Dave Schoorl :
> A slightly different approach: I would talk with the customer again, because
> this is a really stupid (excusez le mot) requirement. I hope you understand
> their motivation, possibly some legacy system that depends on uppercase
> information? Maybe the problem can be shifted to that legacy system that
> uppercases all data read from the database?
>
> Regards,
> Dave
>
>
> Leszek Gawron wrote:
>>
>> Hello,
>>
>> one of my customers has this weird requirement that all data should be
>> input/shown uppercase. I can easily add
>>
>> input {
>> text-transform: uppercase;
>> }
>>
>> to my css rules, but this does not change the fact that data written into
>> database will still be case sensitive.
>>
>> How can I create a behavior for TextField so that the dat is uppercased
>> before being written to the model?
>>
>> my regards
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
A slightly different approach: I would talk with the customer again,
because this is a really stupid (excusez le mot) requirement. I hope you
understand their motivation, possibly some legacy system that depends on
uppercase information? Maybe the problem can be shifted to that legacy
system that uppercases all data read from the database?
Regards,
Dave
Leszek Gawron wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased before being written to the model?
my regards
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
I still feel changing to uppercase in domain model gives you the
flexibility of the changing the values in any layer of the application
taha
On Thu, Mar 5, 2009 at 10:02 AM, Jeremy Thomerson
wrote:
> Oh, actually, just for the record, I was kidding about that. That was my
> facetious / sarcastic tone that unfortunately doesn't come through all that
> well in email (although Igor picked it up). But, more power to you - there
> are certainly plenty of options!
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Wed, Mar 4, 2009 at 10:30 PM, taha siddiqi wrote:
>
>> Hi
>>
>> I have to agree with Jeremy. I would change the domain model and in
>> case i must do it in Wicket I will use I will try to configure a
>> Listener for a general purpose uppercase behavior
>>
>> taha
>>
>> On Thu, Mar 5, 2009 at 7:26 AM, James Carman
>> wrote:
>> > On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
>> > wrote:
>> >> LOL! Nah - I would just change all the setters on every domain object
>> to
>> >> be:
>> >>
>> >> public void setFoo(String foo) {
>> >> this.foo = foo == null ? null : foo.toUpperCase();
>> >> }
>> >>
>> >> Or, maybe I'd use AOP and build an aspect that could automatically
>> intercept
>> >> calls to com.mydomain setters that take a single string argument and do
>> the
>> >> upper-casing there!
>> >
>> > Instead of doing it on *all* single-string argument methods, you could
>> > annotate the parameters:
>> >
>> > public void setFoo(@Upcase String foo)
>> > {
>> > this.foo = foo;
>> > }
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Oh, actually, just for the record, I was kidding about that. That was my
facetious / sarcastic tone that unfortunately doesn't come through all that
well in email (although Igor picked it up). But, more power to you - there
are certainly plenty of options!
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 10:30 PM, taha siddiqi wrote:
> Hi
>
> I have to agree with Jeremy. I would change the domain model and in
> case i must do it in Wicket I will use I will try to configure a
> Listener for a general purpose uppercase behavior
>
> taha
>
> On Thu, Mar 5, 2009 at 7:26 AM, James Carman
> wrote:
> > On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
> > wrote:
> >> LOL! Nah - I would just change all the setters on every domain object
> to
> >> be:
> >>
> >> public void setFoo(String foo) {
> >> this.foo = foo == null ? null : foo.toUpperCase();
> >> }
> >>
> >> Or, maybe I'd use AOP and build an aspect that could automatically
> intercept
> >> calls to com.mydomain setters that take a single string argument and do
> the
> >> upper-casing there!
> >
> > Instead of doing it on *all* single-string argument methods, you could
> > annotate the parameters:
> >
> > public void setFoo(@Upcase String foo)
> > {
> > this.foo = foo;
> > }
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Uppercasing inputs
Hi
I have to agree with Jeremy. I would change the domain model and in
case i must do it in Wicket I will use I will try to configure a
Listener for a general purpose uppercase behavior
taha
On Thu, Mar 5, 2009 at 7:26 AM, James Carman
wrote:
> On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically intercept
>> calls to com.mydomain setters that take a single string argument and do the
>> upper-casing there!
>
> Instead of doing it on *all* single-string argument methods, you could
> annotate the parameters:
>
> public void setFoo(@Upcase String foo)
> {
> this.foo = foo;
> }
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
wrote:
> LOL! Nah - I would just change all the setters on every domain object to
> be:
>
> public void setFoo(String foo) {
> this.foo = foo == null ? null : foo.toUpperCase();
> }
>
> Or, maybe I'd use AOP and build an aspect that could automatically intercept
> calls to com.mydomain setters that take a single string argument and do the
> upper-casing there!
Instead of doing it on *all* single-string argument methods, you could
annotate the parameters:
public void setFoo(@Upcase String foo)
{
this.foo = foo;
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Igor,
... hence the ;-)
The point is worth making for others who come across this thread, and, just
as much, in response to some of the other solutions suggested.
I don't think there's any more to be milked out of this thread.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
>
> sigh, i was being sarcastic. i frankensteined both yours and jeremy's
> ideas together into a solution that used both and was needlessly
> complex.
>
> -igor
>
>
> On Wed, Mar 4, 2009 at 3:59 PM, jWeekend
> wrote:
>>
>> Igor,
>>
>> Still no ;-)
>> A key point is that conversion should happen before validation so you can
>> check if the transformed data (not just the plain text) is valid.
>> Otherwise,
>> what is your validation good for?
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>> PS You are still going to help when I get stuck, aren't you?
>> PPS Is PTF pause for thought, or were you swearing?
>>
>>
>>
>> igor.vaynberg wrote:
>>>
>>> you can create a convertermodel that takes an instance of iconverter
>>> and uses that to convert the values, then you can subclass textfield,
>>> override initmodel() and wrap any model the textfield had with this
>>> one.
>>>
>>> that way everyone is happy!
>>>
>>> -igor
>>>
>>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>>> wrote:
>>>> LOL! Nah - I would just change all the setters on every domain object
>>>> to
>>>> be:
>>>>
>>>> public void setFoo(String foo) {
>>>> this.foo = foo == null ? null : foo.toUpperCase();
>>>> }
>>>>
>>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>>> intercept
>>>> calls to com.mydomain setters that take a single string argument and do
>>>> the
>>>> upper-casing there!
>>>>
>>>> It's makes me smile to think of how many ways a single thing can be
>>>> done.
>>>>
>>>> Leszek - you should now definitely have plenty of choices. Pick which
>>>> feels
>>>> best / most comfortable for you!
>>>>
>>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>>> wrote:
>>>>
>>>>>
>>>>> Igor,
>>>>>
>>>>> Nope, not for me (this time).
>>>>> Here's the Javadoc for updateModel:
>>>>> * Updates this components model from the request, it expects
>>>>> that
>>>>> the
>>>>> object is already
>>>>> * converted through the convertInput() call that is called by
>>>>> the
>>>>> validate() method when a form
>>>>> * is being processed.
>>>>>
>>>>> Regards - Cemal
>>>>> http://jWeekend.com jWeekend
>>>>>
>>>>>
>>>>> igor.vaynberg wrote:
>>>>> >
>>>>> > pft, you guys!
>>>>> >
>>>>> > i would go with the simplest!
>>>>> >
>>>>> > class uppercasetextfield extends textfield {
>>>>> > public void updatemodel()
>>>>> > {
>>>>> > final String str=getconvertedinput();
>>>>> >
>>>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>>>> > }
>>>>> > }
>>>>> >
>>>>> > done!
>>>>> >
>>>>> > -igor
>>>>> >
>>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>>>>
>>>>> > wrote:
>>>>> >>
>>>>> >> Jeremy,
>>>>> >>
>>>>> >> I sensed you were uncomfortable with my "most Wicket-way"
>>>>> suggestion
>>>>> when
>>>>> >> I
>>>>> >> read
>>>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>>>> >> previous post on this thread stating that the model doing the
>>>>> >> transformation work was on the "right track"; it is not unusual
>>>>> that
>>>>> more
>>>>> >> than one design can satisfy a given requirement.
>>>>> >>
>>>>> >> Do you like
Re: Uppercasing inputs
sigh, i was being sarcastic. i frankensteined both yours and jeremy's
ideas together into a solution that used both and was needlessly
complex.
-igor
On Wed, Mar 4, 2009 at 3:59 PM, jWeekend wrote:
>
> Igor,
>
> Still no ;-)
> A key point is that conversion should happen before validation so you can
> check if the transformed data (not just the plain text) is valid. Otherwise,
> what is your validation good for?
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
> PS You are still going to help when I get stuck, aren't you?
> PPS Is PTF pause for thought, or were you swearing?
>
>
>
> igor.vaynberg wrote:
>>
>> you can create a convertermodel that takes an instance of iconverter
>> and uses that to convert the values, then you can subclass textfield,
>> override initmodel() and wrap any model the textfield had with this
>> one.
>>
>> that way everyone is happy!
>>
>> -igor
>>
>> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
>> wrote:
>>> LOL! Nah - I would just change all the setters on every domain object to
>>> be:
>>>
>>> public void setFoo(String foo) {
>>> this.foo = foo == null ? null : foo.toUpperCase();
>>> }
>>>
>>> Or, maybe I'd use AOP and build an aspect that could automatically
>>> intercept
>>> calls to com.mydomain setters that take a single string argument and do
>>> the
>>> upper-casing there!
>>>
>>> It's makes me smile to think of how many ways a single thing can be done.
>>>
>>> Leszek - you should now definitely have plenty of choices. Pick which
>>> feels
>>> best / most comfortable for you!
>>>
>>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>>> wrote:
>>>
>>>>
>>>> Igor,
>>>>
>>>> Nope, not for me (this time).
>>>> Here's the Javadoc for updateModel:
>>>> * Updates this components model from the request, it expects
>>>> that
>>>> the
>>>> object is already
>>>> * converted through the convertInput() call that is called by
>>>> the
>>>> validate() method when a form
>>>> * is being processed.
>>>>
>>>> Regards - Cemal
>>>> http://jWeekend.com jWeekend
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>> >
>>>> > pft, you guys!
>>>> >
>>>> > i would go with the simplest!
>>>> >
>>>> > class uppercasetextfield extends textfield {
>>>> > public void updatemodel()
>>>> > {
>>>> > final String str=getconvertedinput();
>>>> >
>>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>>> > }
>>>> > }
>>>> >
>>>> > done!
>>>> >
>>>> > -igor
>>>> >
>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>>> > wrote:
>>>> >>
>>>> >> Jeremy,
>>>> >>
>>>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>>>> when
>>>> >> I
>>>> >> read
>>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>>> >> previous post on this thread stating that the model doing the
>>>> >> transformation work was on the "right track"; it is not unusual that
>>>> more
>>>> >> than one design can satisfy a given requirement.
>>>> >>
>>>> >> Do you like the idea of a model being responsible for conversion of
>>>> >> users'
>>>> >> textual input?
>>>> >>
>>>> >> Your article illustrates the use of nested models nicely but on this
>>>> >> occasion I would probably go with
>>>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
>>>> Adriano's
>>>> >> idea
>>>> >> for a client side, instant gratification, solution, and a custom text
>>>> >> field
>>>> >> with a converter if the conversion can happen later, on the server.
>>>> >>
>>>> >> Regards - Cemal
>>>> >> http://jWeekend.com jWeekend
>>>> >>
>>>> >>
>>>> >
Re: Uppercasing inputs
Igor,
Still no ;-)
A key point is that conversion should happen before validation so you can
check if the transformed data (not just the plain text) is valid. Otherwise,
what is your validation good for?
Regards - Cemal
http://jWeekend.com jWeekend
PS You are still going to help when I get stuck, aren't you?
PPS Is PTF pause for thought, or were you swearing?
igor.vaynberg wrote:
>
> you can create a convertermodel that takes an instance of iconverter
> and uses that to convert the values, then you can subclass textfield,
> override initmodel() and wrap any model the textfield had with this
> one.
>
> that way everyone is happy!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
> wrote:
>> LOL! Nah - I would just change all the setters on every domain object to
>> be:
>>
>> public void setFoo(String foo) {
>> this.foo = foo == null ? null : foo.toUpperCase();
>> }
>>
>> Or, maybe I'd use AOP and build an aspect that could automatically
>> intercept
>> calls to com.mydomain setters that take a single string argument and do
>> the
>> upper-casing there!
>>
>> It's makes me smile to think of how many ways a single thing can be done.
>>
>> Leszek - you should now definitely have plenty of choices. Pick which
>> feels
>> best / most comfortable for you!
>>
>> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend
>> wrote:
>>
>>>
>>> Igor,
>>>
>>> Nope, not for me (this time).
>>> Here's the Javadoc for updateModel:
>>> * Updates this components model from the request, it expects
>>> that
>>> the
>>> object is already
>>> * converted through the convertInput() call that is called by
>>> the
>>> validate() method when a form
>>> * is being processed.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> igor.vaynberg wrote:
>>> >
>>> > pft, you guys!
>>> >
>>> > i would go with the simplest!
>>> >
>>> > class uppercasetextfield extends textfield {
>>> > public void updatemodel()
>>> > {
>>> > final String str=getconvertedinput();
>>> >
>>> setdefaultmodelobject((str==null)?null:str.touppercase());
>>> > }
>>> > }
>>> >
>>> > done!
>>> >
>>> > -igor
>>> >
>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>>> > wrote:
>>> >>
>>> >> Jeremy,
>>> >>
>>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>>> when
>>> >> I
>>> >> read
>>> http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>>> >> previous post on this thread stating that the model doing the
>>> >> transformation work was on the "right track"; it is not unusual that
>>> more
>>> >> than one design can satisfy a given requirement.
>>> >>
>>> >> Do you like the idea of a model being responsible for conversion of
>>> >> users'
>>> >> textual input?
>>> >>
>>> >> Your article illustrates the use of nested models nicely but on this
>>> >> occasion I would probably go with
>>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html
>>> Adriano's
>>> >> idea
>>> >> for a client side, instant gratification, solution, and a custom text
>>> >> field
>>> >> with a converter if the conversion can happen later, on the server.
>>> >>
>>> >> Regards - Cemal
>>> >> http://jWeekend.com jWeekend
>>> >>
>>> >>
>>> >>
>>> >> Jeremy Thomerson-5 wrote:
>>> >>>
>>> >>> Cemal,
>>> >>> I think I have to respectfully disagree with you here. I describe
>>> >>> what
>>> >>> I
>>> >>> feel is a better solution, and a little bit of why in this blog post
>>> >>> from
>>> >>> a
>>> >>> few months ago:
>>> >>>
>>> >>>
>>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>> >>>
>>> >>> Basically, doing
Re: Uppercasing inputs
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
wrote:
> LOL! Nah - I would just change all the setters on every domain object to
> be:
>
> public void setFoo(String foo) {
> this.foo = foo == null ? null : foo.toUpperCase();
> }
>
> Or, maybe I'd use AOP and build an aspect that could automatically intercept
> calls to com.mydomain setters that take a single string argument and do the
> upper-casing there!
>
> It's makes me smile to think of how many ways a single thing can be done.
>
> Leszek - you should now definitely have plenty of choices. Pick which feels
> best / most comfortable for you!
>
> On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
>
>>
>> Igor,
>>
>> Nope, not for me (this time).
>> Here's the Javadoc for updateModel:
>> * Updates this components model from the request, it expects that
>> the
>> object is already
>> * converted through the convertInput() call that is called by the
>> validate() method when a form
>> * is being processed.
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>> igor.vaynberg wrote:
>> >
>> > pft, you guys!
>> >
>> > i would go with the simplest!
>> >
>> > class uppercasetextfield extends textfield {
>> > public void updatemodel()
>> > {
>> > final String str=getconvertedinput();
>> > setdefaultmodelobject((str==null)?null:str.touppercase());
>> > }
>> > }
>> >
>> > done!
>> >
>> > -igor
>> >
>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
>> > wrote:
>> >>
>> >> Jeremy,
>> >>
>> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
>> when
>> >> I
>> >> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
>> >> previous post on this thread stating that the model doing the
>> >> transformation work was on the "right track"; it is not unusual that
>> more
>> >> than one design can satisfy a given requirement.
>> >>
>> >> Do you like the idea of a model being responsible for conversion of
>> >> users'
>> >> textual input?
>> >>
>> >> Your article illustrates the use of nested models nicely but on this
>> >> occasion I would probably go with
>> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
>> >> idea
>> >> for a client side, instant gratification, solution, and a custom text
>> >> field
>> >> with a converter if the conversion can happen later, on the server.
>> >>
>> >> Regards - Cemal
>> >> http://jWeekend.com jWeekend
>> >>
>> >>
>> >>
>> >> Jeremy Thomerson-5 wrote:
>> >>>
>> >>> Cemal,
>> >>> I think I have to respectfully disagree with you here. I describe
>> >>> what
>> >>> I
>> >>> feel is a better solution, and a little bit of why in this blog post
>> >>> from
>> >>> a
>> >>> few months ago:
>> >>>
>> >>>
>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>> >>>
>> >>> Basically, doing it the way you suggested isn't reusable across many
>> >>> components - you have to create overridden variants of each type of
>> >>> input.
>> >>> Also, a converter (or more specifically, an implementation of
>> >>> IConverter)
>> >>> is
>> >>> supposed to be for transforming a type of object to a string usable in
>> >>> the
>> >>> browser / form post / etc, as it's javadoc mentions.
>> >>>
>> >>> Anyway, as the saying goes "there are many ways to skin a cat" -
>> >>> although
>> >>> the saying isn't that great, I think it applies - there are multiple
>> >>> ways
>> >>> of
>> >>> accomplishing the same thing.
>> >>>
Re: Uppercasing inputs
LOL! Nah - I would just change all the setters on every domain object to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically intercept
calls to com.mydomain setters that take a single string argument and do the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be done.
Leszek - you should now definitely have plenty of choices. Pick which feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend wrote:
>
> Igor,
>
> Nope, not for me (this time).
> Here's the Javadoc for updateModel:
> * Updates this components model from the request, it expects that
> the
> object is already
> * converted through the convertInput() call that is called by the
> validate() method when a form
> * is being processed.
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> igor.vaynberg wrote:
> >
> > pft, you guys!
> >
> > i would go with the simplest!
> >
> > class uppercasetextfield extends textfield {
> > public void updatemodel()
> > {
> > final String str=getconvertedinput();
> > setdefaultmodelobject((str==null)?null:str.touppercase());
> > }
> > }
> >
> > done!
> >
> > -igor
> >
> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
> > wrote:
> >>
> >> Jeremy,
> >>
> >> I sensed you were uncomfortable with my "most Wicket-way" suggestion
> when
> >> I
> >> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.htmlyour
> >> previous post on this thread stating that the model doing the
> >> transformation work was on the "right track"; it is not unusual that
> more
> >> than one design can satisfy a given requirement.
> >>
> >> Do you like the idea of a model being responsible for conversion of
> >> users'
> >> textual input?
> >>
> >> Your article illustrates the use of nested models nicely but on this
> >> occasion I would probably go with
> >> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
> >> idea
> >> for a client side, instant gratification, solution, and a custom text
> >> field
> >> with a converter if the conversion can happen later, on the server.
> >>
> >> Regards - Cemal
> >> http://jWeekend.com jWeekend
> >>
> >>
> >>
> >> Jeremy Thomerson-5 wrote:
> >>>
> >>> Cemal,
> >>> I think I have to respectfully disagree with you here. I describe
> >>> what
> >>> I
> >>> feel is a better solution, and a little bit of why in this blog post
> >>> from
> >>> a
> >>> few months ago:
> >>>
> >>>
> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
> >>>
> >>> Basically, doing it the way you suggested isn't reusable across many
> >>> components - you have to create overridden variants of each type of
> >>> input.
> >>> Also, a converter (or more specifically, an implementation of
> >>> IConverter)
> >>> is
> >>> supposed to be for transforming a type of object to a string usable in
> >>> the
> >>> browser / form post / etc, as it's javadoc mentions.
> >>>
> >>> Anyway, as the saying goes "there are many ways to skin a cat" -
> >>> although
> >>> the saying isn't that great, I think it applies - there are multiple
> >>> ways
> >>> of
> >>> accomplishing the same thing.
> >>>
> >>> --
> >>> Jeremy Thomerson
> >>> http://www.wickettraining.com
> >>>
> >>>
> >>> On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
> >>> wrote:
> >>>
> >>>>
> >>>> Leszek,
> >>>>
> >>>> ... or, probably the most "Wicket-way" of doing this is to make a
> >>>> TextField
> >>>> subclass that overrides getConverter to return your special IConverter
> >>>> implementation which performs the capitalisation in its
> >>>> convertToObject.
> >>>>
> >>>> Regards - Cemal
> >>>> http://jWee
Re: Uppercasing inputs
Igor,
Nope, not for me (this time).
Here's the Javadoc for updateModel:
* Updates this components model from the request, it expects that the
object is already
* converted through the convertInput() call that is called by the
validate() method when a form
* is being processed.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
>
> pft, you guys!
>
> i would go with the simplest!
>
> class uppercasetextfield extends textfield {
> public void updatemodel()
> {
> final String str=getconvertedinput();
> setdefaultmodelobject((str==null)?null:str.touppercase());
> }
> }
>
> done!
>
> -igor
>
> On Wed, Mar 4, 2009 at 3:07 PM, jWeekend
> wrote:
>>
>> Jeremy,
>>
>> I sensed you were uncomfortable with my "most Wicket-way" suggestion when
>> I
>> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.html your
>> previous post on this thread stating that the model doing the
>> transformation work was on the "right track"; it is not unusual that more
>> than one design can satisfy a given requirement.
>>
>> Do you like the idea of a model being responsible for conversion of
>> users'
>> textual input?
>>
>> Your article illustrates the use of nested models nicely but on this
>> occasion I would probably go with
>> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's
>> idea
>> for a client side, instant gratification, solution, and a custom text
>> field
>> with a converter if the conversion can happen later, on the server.
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>>
>> Jeremy Thomerson-5 wrote:
>>>
>>> Cemal,
>>> I think I have to respectfully disagree with you here. I describe
>>> what
>>> I
>>> feel is a better solution, and a little bit of why in this blog post
>>> from
>>> a
>>> few months ago:
>>>
>>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>>
>>> Basically, doing it the way you suggested isn't reusable across many
>>> components - you have to create overridden variants of each type of
>>> input.
>>> Also, a converter (or more specifically, an implementation of
>>> IConverter)
>>> is
>>> supposed to be for transforming a type of object to a string usable in
>>> the
>>> browser / form post / etc, as it's javadoc mentions.
>>>
>>> Anyway, as the saying goes "there are many ways to skin a cat" -
>>> although
>>> the saying isn't that great, I think it applies - there are multiple
>>> ways
>>> of
>>> accomplishing the same thing.
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>>> On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
>>> wrote:
>>>
>>>>
>>>> Leszek,
>>>>
>>>> ... or, probably the most "Wicket-way" of doing this is to make a
>>>> TextField
>>>> subclass that overrides getConverter to return your special IConverter
>>>> implementation which performs the capitalisation in its
>>>> convertToObject.
>>>>
>>>> Regards - Cemal
>>>> http://jWeekend.com jWeekend
>>>>
>>>>
>>>> Leszek Gawron-2 wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > one of my customers has this weird requirement that all data should
>>>> be
>>>> > input/shown uppercase. I can easily add
>>>> >
>>>> > input {
>>>> > text-transform: uppercase;
>>>> > }
>>>> >
>>>> > to my css rules, but this does not change the fact that data written
>>>> > into database will still be case sensitive.
>>>> >
>>>> > How can I create a behavior for TextField so that the dat is
>>>> uppercased
>>>> > before being written to the model?
>>>> >
>>>> > my regards
>>>> >
>>>> > --
>>>> > Leszek Gawron
>>>> >
>>>> > -
>>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> > For additional commands, e-mail: users
Re: Uppercasing inputs
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield {
public void updatemodel()
{
final String str=getconvertedinput();
setdefaultmodelobject((str==null)?null:str.touppercase());
}
}
done!
-igor
On Wed, Mar 4, 2009 at 3:07 PM, jWeekend wrote:
>
> Jeremy,
>
> I sensed you were uncomfortable with my "most Wicket-way" suggestion when I
> read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.html your
> previous post on this thread stating that the model doing the
> transformation work was on the "right track"; it is not unusual that more
> than one design can satisfy a given requirement.
>
> Do you like the idea of a model being responsible for conversion of users'
> textual input?
>
> Your article illustrates the use of nested models nicely but on this
> occasion I would probably go with
> http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's idea
> for a client side, instant gratification, solution, and a custom text field
> with a converter if the conversion can happen later, on the server.
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
>
> Jeremy Thomerson-5 wrote:
>>
>> Cemal,
>> I think I have to respectfully disagree with you here. I describe what
>> I
>> feel is a better solution, and a little bit of why in this blog post from
>> a
>> few months ago:
>>
>> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>>
>> Basically, doing it the way you suggested isn't reusable across many
>> components - you have to create overridden variants of each type of input.
>> Also, a converter (or more specifically, an implementation of IConverter)
>> is
>> supposed to be for transforming a type of object to a string usable in the
>> browser / form post / etc, as it's javadoc mentions.
>>
>> Anyway, as the saying goes "there are many ways to skin a cat" -
>> although
>> the saying isn't that great, I think it applies - there are multiple ways
>> of
>> accomplishing the same thing.
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>>
>> On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
>> wrote:
>>
>>>
>>> Leszek,
>>>
>>> ... or, probably the most "Wicket-way" of doing this is to make a
>>> TextField
>>> subclass that overrides getConverter to return your special IConverter
>>> implementation which performs the capitalisation in its convertToObject.
>>>
>>> Regards - Cemal
>>> http://jWeekend.com jWeekend
>>>
>>>
>>> Leszek Gawron-2 wrote:
>>> >
>>> > Hello,
>>> >
>>> > one of my customers has this weird requirement that all data should be
>>> > input/shown uppercase. I can easily add
>>> >
>>> > input {
>>> > text-transform: uppercase;
>>> > }
>>> >
>>> > to my css rules, but this does not change the fact that data written
>>> > into database will still be case sensitive.
>>> >
>>> > How can I create a behavior for TextField so that the dat is uppercased
>>> > before being written to the model?
>>> >
>>> > my regards
>>> >
>>> > --
>>> > Leszek Gawron
>>> >
>>> > -----
>>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> > For additional commands, e-mail: users-h...@wicket.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Jeremy,
I sensed you were uncomfortable with my "most Wicket-way" suggestion when I
read http://www.nabble.com/RE%3A-Uppercasing-inputs-p22338461.html your
previous post on this thread stating that the model doing the
transformation work was on the "right track"; it is not unusual that more
than one design can satisfy a given requirement.
Do you like the idea of a model being responsible for conversion of users'
textual input?
Your article illustrates the use of nested models nicely but on this
occasion I would probably go with
http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's idea
for a client side, instant gratification, solution, and a custom text field
with a converter if the conversion can happen later, on the server.
Regards - Cemal
http://jWeekend.com jWeekend
Jeremy Thomerson-5 wrote:
>
> Cemal,
> I think I have to respectfully disagree with you here. I describe what
> I
> feel is a better solution, and a little bit of why in this blog post from
> a
> few months ago:
>
> http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
>
> Basically, doing it the way you suggested isn't reusable across many
> components - you have to create overridden variants of each type of input.
> Also, a converter (or more specifically, an implementation of IConverter)
> is
> supposed to be for transforming a type of object to a string usable in the
> browser / form post / etc, as it's javadoc mentions.
>
> Anyway, as the saying goes "there are many ways to skin a cat" -
> although
> the saying isn't that great, I think it applies - there are multiple ways
> of
> accomplishing the same thing.
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
>
> On Wed, Mar 4, 2009 at 12:04 PM, jWeekend
> wrote:
>
>>
>> Leszek,
>>
>> ... or, probably the most "Wicket-way" of doing this is to make a
>> TextField
>> subclass that overrides getConverter to return your special IConverter
>> implementation which performs the capitalisation in its convertToObject.
>>
>> Regards - Cemal
>> http://jWeekend.com jWeekend
>>
>>
>> Leszek Gawron-2 wrote:
>> >
>> > Hello,
>> >
>> > one of my customers has this weird requirement that all data should be
>> > input/shown uppercase. I can easily add
>> >
>> > input {
>> >text-transform: uppercase;
>> > }
>> >
>> > to my css rules, but this does not change the fact that data written
>> > into database will still be case sensitive.
>> >
>> > How can I create a behavior for TextField so that the dat is uppercased
>> > before being written to the model?
>> >
>> > my regards
>> >
>> > --
>> > Leszek Gawron
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Cemal,
I think I have to respectfully disagree with you here. I describe what I
feel is a better solution, and a little bit of why in this blog post from a
few months ago:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Basically, doing it the way you suggested isn't reusable across many
components - you have to create overridden variants of each type of input.
Also, a converter (or more specifically, an implementation of IConverter) is
supposed to be for transforming a type of object to a string usable in the
browser / form post / etc, as it's javadoc mentions.
Anyway, as the saying goes "there are many ways to skin a cat" - although
the saying isn't that great, I think it applies - there are multiple ways of
accomplishing the same thing.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 12:04 PM, jWeekend wrote:
>
> Leszek,
>
> ... or, probably the most "Wicket-way" of doing this is to make a TextField
> subclass that overrides getConverter to return your special IConverter
> implementation which performs the capitalisation in its convertToObject.
>
> Regards - Cemal
> http://jWeekend.com jWeekend
>
>
> Leszek Gawron-2 wrote:
> >
> > Hello,
> >
> > one of my customers has this weird requirement that all data should be
> > input/shown uppercase. I can easily add
> >
> > input {
> >text-transform: uppercase;
> > }
> >
> > to my css rules, but this does not change the fact that data written
> > into database will still be case sensitive.
> >
> > How can I create a behavior for TextField so that the dat is uppercased
> > before being written to the model?
> >
> > my regards
> >
> > --
> > Leszek Gawron
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
RE: Uppercasing inputs
Ernesto's got you on the right track. I'd recommend taking it a step further
like described here:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: Ernesto Reinaldo Barreiro
Sent: Wednesday, March 04, 2009 9:43 AM
To: users@wicket.apache.org
Subject: Re: Uppercasing inputs
Maybe:
class MyUpperCaseModel extends WhatEverModel {
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModel.
Ernesto
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron wrote:
> Hello,
>
> one of my customers has this weird requirement that all data should be
> input/shown uppercase. I can easily add
>
> input {
> text-transform: uppercase;
> }
>
> to my css rules, but this does not change the fact that data written into
> database will still be case sensitive.
>
> How can I create a behavior for TextField so that the dat is uppercased
> before being written to the model?
>
> my regards
>
> --
> Leszek Gawron
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Leszek,
... or, probably the most "Wicket-way" of doing this is to make a TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
>
> Hello,
>
> one of my customers has this weird requirement that all data should be
> input/shown uppercase. I can easily add
>
> input {
>text-transform: uppercase;
> }
>
> to my css rules, but this does not change the fact that data written
> into database will still be case sensitive.
>
> How can I create a behavior for TextField so that the dat is uppercased
> before being written to the model?
>
> my regards
>
> --
> Leszek Gawron
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Maybe:
class MyUpperCaseModel extends WhatEverModel {
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModel.
Ernesto
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron wrote:
> Hello,
>
> one of my customers has this weird requirement that all data should be
> input/shown uppercase. I can easily add
>
> input {
> text-transform: uppercase;
> }
>
> to my css rules, but this does not change the fact that data written into
> database will still be case sensitive.
>
> How can I create a behavior for TextField so that the dat is uppercased
> before being written to the model?
>
> my regards
>
> --
> Leszek Gawron
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Uppercasing inputs
public class UpperCaseBehavior extends AttributeAppender
{
private static final long serialVersionUID = 1L;
public UpperCaseBehavior()
{
super("style", new Model("text-transform: uppercase"), ";");
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
"onkeyup", new Model("this.value =
this.value.toUpperCase()"), ";"));
}
}
Leszek Gawron escreveu:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased before being written to the model?
my regards
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Uppercasing inputs
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
