You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Leszek Gawron <lg...@apache.org> on 2009/03/04 16:30:11 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by taha siddiqi <ta...@gmail.com>.
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 <lg...@apache.org> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Leszek Gawron <lg...@apache.org>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by taha siddiqi <ta...@gmail.com>.
Thanks!!( everyone MADE a joke and I BECAME one )
On Fri, Mar 6, 2009 at 3:55 PM, Leszek Gawron <lg...@apache.org> 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<String>("text-transform: uppercase"), ";");
>> }
>>
>> @Override
>> public void bind(Component component)
>> {
>> super.bind(component);
>> component.add(new AttributeAppender(
>> "onkeyup", new Model<String>("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<string> {
>> 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<Role> roles = new HashSet<Role>();
>> 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
> 51870721134999999837297804995105973173281609631859
> 50244594553469083026425223082533446850352619311881
> 71010003137838752886587533208381420617177669147303
> 59825349042875546873115956286388235378759375195778
> 18577805321712268066130019278766111959092164201989
> 38095257201065485863278865936153381827968230301952
> 03530185296899577362259941389124972177528347913151
> 55748572424541506959508295331168617278558890750983
> 81754637464939319255060400927701671139009848824012
> 85836160356370766010471018194295559619894676783744
> 94482553797747268471040475346462080466842590694912
> 93313677028989152104752162056966024058038150193511
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Leszek Gawron <lg...@apache.org>.
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<String>("text-transform: uppercase"), ";");
> }
>
> @Override
> public void bind(Component component)
> {
> super.bind(component);
> component.add(new AttributeAppender(
> "onkeyup", new Model<String>("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<string> {
> 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<Role> roles = new HashSet<Role>();
> 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
51870721134999999837297804995105973173281609631859
50244594553469083026425223082533446850352619311881
71010003137838752886587533208381420617177669147303
59825349042875546873115956286388235378759375195778
18577805321712268066130019278766111959092164201989
38095257201065485863278865936153381827968230301952
03530185296899577362259941389124972177528347913151
55748572424541506959508295331168617278558890750983
81754637464939319255060400927701671139009848824012
85836160356370766010471018194295559619894676783744
94482553797747268471040475346462080466842590694912
93313677028989152104752162056966024058038150193511
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Peter Ertl <pe...@gmx.org>.
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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Adriano dos Santos Fernandes <ad...@gmail.com>.
public class UpperCaseBehavior extends AttributeAppender
{
private static final long serialVersionUID = 1L;
public UpperCaseBehavior()
{
super("style", new Model<String>("text-transform: uppercase"), ";");
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
"onkeyup", new Model<String>("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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Maybe:
class MyUpperCaseModel extends WhatEverModel<String> {
............
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModel<String>.
Ernesto
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron <lg...@apache.org> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Uppercasing inputs
Posted by taha siddiqi <ta...@gmail.com>.
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
<je...@wickettraining.com> 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 <ta...@gmail.com> 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
>> <jc...@carmanconsulting.com> wrote:
>> > On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
>> > <je...@wickettraining.com> 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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <ta...@gmail.com> 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
> <jc...@carmanconsulting.com> wrote:
> > On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
> > <je...@wickettraining.com> 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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Uppercasing inputs
Posted by taha siddiqi <ta...@gmail.com>.
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
<jc...@carmanconsulting.com> wrote:
> On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
> <je...@wickettraining.com> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by James Carman <jc...@carmanconsulting.com>.
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
<je...@wickettraining.com> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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 <jw...@cabouge.com>
> 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
>>> <je...@wickettraining.com> 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
>>>> <jw...@cabouge.com>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<string> {
>>>>> > 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
>>>>> <jw...@cabouge.com>
>>>>> > 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
>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22342462.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22342774.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jw...@cabouge.com> 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
>> <je...@wickettraining.com> 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
>>> <jw...@cabouge.com>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<string> {
>>>> > 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 <jw...@cabouge.com>
>>>> > 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
>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22342462.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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
> <je...@wickettraining.com> 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
>> <jw...@cabouge.com>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<string> {
>>> > 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 <jw...@cabouge.com>
>>> > 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
>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22342462.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Marcelo Morales <ma...@gmail.com>.
I've solved this same requirement on the backend (architecture was
two-layered). Wicket on the front layer had no relation to the
uppercasing.
On java.util.String there are two methods: toUpperCase() and
toUpperCase(Locale locale). I've used the parametrized one with the
user's locale. I am not sure if it is good practice, or even if it has
different results, but I did it just in case.
Regards
On Thu, Mar 5, 2009 at 12:12 PM, jWeekend <jw...@cabouge.com> 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?
>
> 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 <jw...@cabouge.com>
>> 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 <ig...@gmail.com>
>>>> 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
>>>>> <je...@wickettraining.com> 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
>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>> > 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
>>>>>>> <jw...@cabouge.com>
>>>>>>> > 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
>>>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://www.wickettraining.com
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>> Apache Wicket 1.3.5 is released
>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Marcelo Morales
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Maarten Bosteels <mb...@gmail.com>.
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 <ig...@gmail.com>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 <pe...@gmx.org> 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 <jw...@cabouge.com>
> >>> 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 <
> jweekend_forums@cabouge.com>
> >>>>> 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
> >>>>>>> <ig...@gmail.com>
> >>>>>>> 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
> >>>>>>>> <je...@wickettraining.com> 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
> >>>>>>>>> <jw...@cabouge.com>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<string> {
> >>>>>>>>>>> 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
> >>>>>>>>>>
> >>>>>>>>>> <jw...@cabouge.com>
> >>>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>
> >>>>>>>>>> users-help@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> users-help@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>
> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> View this message in context:
> >>>>>>>>>>
> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
> >>>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Jeremy Thomerson
> >>>>>>>>> http://www.wickettraining.com
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Become a Wicket expert, learn from the best:
> >>>>>>> http://wicketinaction.com
> >>>>>>> Apache Wicket 1.3.5 is released
> >>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> View this message in context:
> >>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
> >>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
> >>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <pe...@gmx.org> 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 <jw...@cabouge.com>
>>> 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 <jw...@cabouge.com>
>>>>> 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
>>>>>>> <ig...@gmail.com>
>>>>>>> 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
>>>>>>>> <je...@wickettraining.com> 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
>>>>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> <jw...@cabouge.com>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>
>>>>>>>>>> users-help@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jeremy Thomerson
>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Become a Wicket expert, learn from the best:
>>>>>>> http://wicketinaction.com
>>>>>>> Apache Wicket 1.3.5 is released
>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Peter Ertl <pe...@gmx.org>.
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
>>>> <jw...@cabouge.com>
>>>> 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 <jweekend_forums@cabouge.com
>>>>>>>
>>>>>> 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
>>>>>>>> <ig...@gmail.com>
>>>>>>>> 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
>>>>>>>>> <je...@wickettraining.com> 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
>>>>>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>>>>>>> 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
>>>>>>>>>>> <jw...@cabouge.com>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> users-help@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-
>>>>>>>>>>>>>>> unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@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-
>>>>>>>>>>>>> unsubscribe@wicket.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>>>>>> help@wicket.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>>>>>> Sent from the Wicket - User mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>>>> help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jeremy Thomerson
>>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Become a Wicket expert, learn from the best:
>>>>>>>> http://wicketinaction.com
>>>>>>>> Apache Wicket 1.3.5 is released
>>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Uppercasing-inputs-
>>>>>>> tp22332360p22347989.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22357058.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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
>>> <jw...@cabouge.com>
>>> 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 <jweekend_forums@cabouge.com
>>>>> >
>>>>> 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
>>>>>>> <ig...@gmail.com>
>>>>>>> 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
>>>>>>>> <je...@wickettraining.com> 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
>>>>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>>>>>> 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
>>>>>>>>>> <jw...@cabouge.com>
>>>>>>>>>>> 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
>>>>>>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> users-help@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-
>>>>>>>>>>>>>> unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>>>>> help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>>>>> Sent from the Wicket - User mailing list archive at
>>>>>>>>>> Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jeremy Thomerson
>>>>>>>>> http://www.wickettraining.com
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Become a Wicket expert, learn from the best:
>>>>>>> http://wicketinaction.com
>>>>>>> Apache Wicket 1.3.5 is released
>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22357058.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Peter Ertl <pe...@gmx.org>.
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
>> <jw...@cabouge.com>
>> 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 <jweekend_forums@cabouge.com
>>>> >
>>>> 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
>>>>>> <ig...@gmail.com>
>>>>>> 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
>>>>>>> <je...@wickettraining.com> 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
>>>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>>>>> 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
>>>>>>>>> <jw...@cabouge.com>
>>>>>>>>>> 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
>>>>>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>> users-help@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-
>>>>>>>>>>>>> unsubscribe@wicket.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>>>> help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>>>> Sent from the Wicket - User mailing list archive at
>>>>>>>>> Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jeremy Thomerson
>>>>>>>> http://www.wickettraining.com
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>>> Apache Wicket 1.3.5 is released
>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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 <jw...@cabouge.com>
> 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 <jw...@cabouge.com>
>>> 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
>>>>> <ig...@gmail.com>
>>>>> 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
>>>>>> <je...@wickettraining.com> 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
>>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>>> > 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
>>>>>>>> <jw...@cabouge.com>
>>>>>>>> > 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
>>>>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>> >>>> > For additional commands, e-mail:
>>>>>>>> users-help@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-unsubscribe@wicket.apache.org
>>>>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jeremy Thomerson
>>>>>>> http://www.wickettraining.com
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>> Apache Wicket 1.3.5 is released
>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22355520.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 5, 2009 at 8:12 AM, jWeekend <jw...@cabouge.com> 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 <jw...@cabouge.com>
>> 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 <ig...@gmail.com>
>>>> 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
>>>>> <je...@wickettraining.com> 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
>>>>>> <jw...@cabouge.com>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<string> {
>>>>>>> > 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
>>>>>>> <jw...@cabouge.com>
>>>>>>> > 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
>>>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jeremy Thomerson
>>>>>> http://www.wickettraining.com
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>> Apache Wicket 1.3.5 is released
>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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 <jw...@cabouge.com>
> 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 <ig...@gmail.com>
>>> 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
>>>> <je...@wickettraining.com> 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
>>>>> <jw...@cabouge.com>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<string> {
>>>>>> > 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
>>>>>> <jw...@cabouge.com>
>>>>>> > 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
>>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jeremy Thomerson
>>>>> http://www.wickettraining.com
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>> Apache Wicket 1.3.5 is released
>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22354741.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jw...@cabouge.com> 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 <ig...@gmail.com>
>> 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
>>> <je...@wickettraining.com> 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
>>>> <jw...@cabouge.com>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<string> {
>>>>> > 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
>>>>> <jw...@cabouge.com>
>>>>> > 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
>>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>> Apache Wicket 1.3.5 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Peter Ertl <pe...@gmx.org>.
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 <igor.vaynberg@gmail.com
>> >
>> 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
>>> <je...@wickettraining.com> 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
>>>> <jw...@cabouge.com>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<string> {
>>>>>> 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
>>>>> <jw...@cabouge.com>
>>>>>> 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
>>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://www.wickettraining.com
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://
>> wicketinaction.com
>> Apache Wicket 1.3.5 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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 <ig...@gmail.com>
> 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
>> <je...@wickettraining.com> 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
>>> <jw...@cabouge.com>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<string> {
>>>> > 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
>>>> <jw...@cabouge.com>
>>>> > 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
>>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22347989.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Dave Schoorl <ma...@cyber-d.com>.
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 <ig...@gmail.com> 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
>> <je...@wickettraining.com> 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 <jw...@cabouge.com>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<string> {
>>>>> 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 <jw...@cabouge.com>
>>>>> 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
>>>>>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ig...@gmail.com> 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
> <je...@wickettraining.com> 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 <jw...@cabouge.com>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<string> {
>>> > 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 <jw...@cabouge.com>
>>> > 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
>>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>> --
>> Jeremy Thomerson
>> http://www.wickettraining.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<je...@wickettraining.com> 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 <jw...@cabouge.com>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<string> {
>> > 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 <jw...@cabouge.com>
>> > 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
>> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <jw...@cabouge.com>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<string> {
> > 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 <jw...@cabouge.com>
> > 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
> >>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
> >>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Jeremy Thomerson
http://www.wickettraining.com
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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<string> {
> 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 <jw...@cabouge.com>
> 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
>>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22341926.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Igor Vaynberg <ig...@gmail.com>.
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfield<string> {
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 <jw...@cabouge.com> 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
>> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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
> <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Jeremy Thomerson <je...@wickettraining.com>.
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 <jw...@cabouge.com>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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Uppercasing inputs
Posted by jWeekend <jw...@cabouge.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Argh.. and ofcourse, you can uppercase it in your model get/set method.
**
Martin
2009/3/5 Martin Makundi <ma...@koodaripalvelut.com>:
> 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 <ma...@cyber-d.com>:
> - 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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 <ma...@cyber-d.com>:
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Uppercasing inputs
Posted by Dave Schoorl <ma...@cyber-d.com>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org