Re: Uppercasing inputs
Sorry for a late response!! In this part of the world interest works 5-6 hours a day if you are fortunate and yesterday i was not... Man, It is my pleasure to be part of a project which made me most comfortable with j2ee ( I have worked from perl, php, python, asp to .NET, struts, spring MVC ). Hope I will be able to contribute to this project in a few months ... ( right now i am busy with two office projects ) Thanks everybody taha On Fri, Mar 6, 2009 at 8:11 PM, Leszek Gawron lgaw...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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 ModelString(text-transform: uppercase), ;);
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
onkeyup, new ModelString(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 textfieldstring {
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 SetRole roles = new HashSetRole();
private String mobilePhone;
private String workPhone;
private String colour;
}
and:
public aspect Uppercaser {
pointcut setString( String value ) : ( ( set(String (@UpperCased *).* )
set(!...@normalcased String *.* ) )
|| set(@UpperCased String *.* ) )
args( value );
void around( String value ) : setString( value ) {
proceed( StringUtils.upperCase( value ) );
}
}
because:
1. I decided that the uppercasing should available for junit
tests/command line tools etc.
2. It introduces the least changes into existing code.
3. It allows me to get rid of uppercasing just by recompiling the domain
model library without the aspect (if ever my customer came back to
sanity).
It feels like I'm introducing way too complicated tool to solve an easy
task (maybe judging by the number of the posts - not that easy after
all), but what the hell...
Thank you for all posts. You are by no means one of the most helpful and
vigorous OS community there is.
PS. I laughed almost to tears reading some posts. Very refreshing :)
--
Leszek Gawron 3.14159265358979323846264338327950288419716939937510
58209749445923078164062862089986280348253421170679
82148086513282306647093844609550582231725359408128
48111745028410270193852110555964462294895493038196
44288109756659334461284756482337867831652712019091
45648566923460348610454326648213393607260249141273
72458700660631558817488152092096282925409171536436
78925903600113305305488204665213841469519415116094
33057270365759591953092186117381932611793105118548
07446237996274956735188575272489122793818301194912
98336733624406566430860213949463952247371907021798
60943702770539217176293176752384674818467669405132
00056812714526356082778577134275778960917363717872
14684409012249534301465495853710507922796892589235
42019956112129021960864034418159813629774771309960
5187072113499837297804995105973173281609631859
50244594553469083026425223082533446850352619311881
71010003137838752886587533208381420617177669147303
Re: Uppercasing inputs
Thanks!!( everyone MADE a joke and I BECAME one )
On Fri, Mar 6, 2009 at 3:55 PM, Leszek Gawron lgaw...@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 ModelString(text-transform: uppercase), ;);
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
onkeyup, new ModelString(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 textfieldstring {
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 SetRole roles = new HashSetRole();
private String mobilePhone;
private String workPhone;
private String colour;
}
and:
public aspect Uppercaser {
pointcut setString( String value ) : ( ( set(String (@UpperCased
*).* ) set(!...@normalcased String *.* ) )
|| set(@UpperCased String *.* ) )
args( value );
void around( String value ) : setString( value ) {
proceed( StringUtils.upperCase( value ) );
}
}
because:
1. I decided that the uppercasing should available for junit tests/command
line tools etc.
2. It introduces the least changes into existing code.
3. It allows me to get rid of uppercasing just by recompiling the domain
model library without the aspect (if ever my customer came back to
sanity).
It feels like I'm introducing way too complicated tool to solve an easy task
(maybe judging by the number of the posts - not that easy after all), but
what the hell...
Thank you for all posts. You are by no means one of the most helpful and
vigorous OS community there is.
PS. I laughed almost to tears reading some posts. Very refreshing :)
--
Leszek Gawron 3.14159265358979323846264338327950288419716939937510
58209749445923078164062862089986280348253421170679
82148086513282306647093844609550582231725359408128
48111745028410270193852110555964462294895493038196
44288109756659334461284756482337867831652712019091
45648566923460348610454326648213393607260249141273
72458700660631558817488152092096282925409171536436
78925903600113305305488204665213841469519415116094
33057270365759591953092186117381932611793105118548
07446237996274956735188575272489122793818301194912
98336733624406566430860213949463952247371907021798
60943702770539217176293176752384674818467669405132
00056812714526356082778577134275778960917363717872
14684409012249534301465495853710507922796892589235
42019956112129021960864034418159813629774771309960
5187072113499837297804995105973173281609631859
50244594553469083026425223082533446850352619311881
71010003137838752886587533208381420617177669147303
Re: Uppercasing inputs
taha siddiqi wrote: Thanks!!( everyone MADE a joke and I BECAME one ) I'm sorry if you felt offended. It wasn't personal. Maybe my expression was not exact enough. After all I have used your proposal (modify Strings directly in domain model). What I didn't like is the requirement to change every set*( String value ) so I used AspectJ for that (which is probably a total overkill). My regards lg -- Leszek Gawron - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Hi Jeremy,
Nice post! I'll think I'll start using that approach myself more
frequently.
Best,
Ernesto
On Wed, Mar 4, 2009 at 9:19 PM, Jeremy Thomerson
jer...@wickettraining.comwrote:
Ernesto's got you on the right track. I'd recommend taking it a step
further like described here:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: Ernesto Reinaldo Barreiro reier...@gmail.com
Sent: Wednesday, March 04, 2009 9:43 AM
To: users@wicket.apache.org
Subject: Re: Uppercasing inputs
Maybe:
class MyUpperCaseModel extends WhatEverModelString {
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModelString.
Ernesto
- Show quoted text -
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron lgaw...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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.vaynb...@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
jer...@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 jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Re: Uppercasing inputs
LOL! That sounds scalable!
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg igor.vaynb...@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
jer...@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 jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
Re: Uppercasing inputs
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a 5 free conversions trial subscription?
Ether way, I would suggest this be done at conversion time so validation can
do its job properly and you're not handing off conversion responsibilities
where they don't belong. Some solutions leaving this transformation of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of neat
solutions that still manage to upper-case a string; how about just cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE - that would work too, but wouldn't be my choice.
There's also a degree of it depends here, but generally, the
form-processing life-cycle should be respected or explicitly overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg igor.vaynb...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@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
Re: Uppercasing inputs
Yes, I love that mailing list :-)
Am 05.03.2009 um 10:26 schrieb jWeekend:
Martijn,
Is there not already an EasyUpperCaseRUs.com web service you can
subscribe
to for unlimited conversions at an annual fee of under 30,000USD (or
100USD/conversion) who also have a 5 free conversions trial
subscription?
Ether way, I would suggest this be done at conversion time so
validation can
do its job properly and you're not handing off conversion
responsibilities
where they don't belong. Some solutions leaving this transformation
of the
text input by the user until after conversion in the form processing
life-cycle may be less lines of code (or less classes), but IMO, are
bending
rules and ignoring good design principles.
Of course, others may disagree and come up with all sorts of neat
solutions that still manage to upper-case a string; how about just
cut out
the middle-man altogether and do it in a stored-procedure triggered on
INSERT and UPDATE - that would work too, but wouldn't be my choice.
There's also a degree of it depends here, but generally, the
form-processing life-cycle should be respected or explicitly
overridden for
a good design reason (to meet user requirements).
Regards - Cemal
http://jWeekend.com jWeekend
Martijn Dashorst wrote:
I suggest setting up an ESB with a UppercaseService that is available
through EJB/SOAP/JAX-RS and JSON. UppercaseModel could then access
that UppercaseService to make the value uppercase.
Martijn
On Thu, Mar 5, 2009 at 12:50 AM, Igor Vaynberg igor.vaynb...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@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,
Re: Uppercasing inputs
using conversion and validation for this is wrong.
converters in wicket are meant to convert from type-string because
the web is type-agnostic. a string-string conversion is not a
conversion from wicket's point of view. yes, the code is somewhat
unclear, we are going to address this in 1.5 where we can change some
api and better name things.
validation is also wrong. validation checks user input. the
requirement to have this entered in uppercase is not on the user, it
is on the system. so a validator should not fail because something was
entered in non-uppercase.
-igor
On Thu, Mar 5, 2009 at 1:26 AM, jWeekend jweekend_for...@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 igor.vaynb...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@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:
Re: Uppercasing inputs
Igor,
If there was a Java type called UpperCaseString that's what the developer
would use as the underlying object and you would not have this objection.
What's the difference between a converter translating 2009-04-04 to a
java.util.Date or even to a LunchDate which always sets the time part to
midday?
I agree clearly that the translation should not be done by the validator.
Regards - Cemal
http;//jWeekend.com
igor.vaynberg wrote:
using conversion and validation for this is wrong.
converters in wicket are meant to convert from type-string because
the web is type-agnostic. a string-string conversion is not a
conversion from wicket's point of view. yes, the code is somewhat
unclear, we are going to address this in 1.5 where we can change some
api and better name things.
validation is also wrong. validation checks user input. the
requirement to have this entered in uppercase is not on the user, it
is on the system. so a validator should not fail because something was
entered in non-uppercase.
-igor
On Thu, Mar 5, 2009 at 1:26 AM, jWeekend jweekend_for...@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 igor.vaynb...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@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
Re: Uppercasing inputs
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 jweekend_for...@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 jweekend_for...@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 igor.vaynb...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@cabouge.com
wrote:
Jeremy,
I sensed you were uncomfortable with my most Wicket-way
suggestion
when
I
read
Re: Uppercasing inputs
Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper-case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs-p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend jweekend_for...@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_for...@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 igor.vaynb...@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,
Re: Uppercasing inputs
On Thu, Mar 5, 2009 at 8:12 AM, jWeekend jweekend_for...@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_for...@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 igor.vaynb...@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
jer...@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
Re: Uppercasing inputs
So what's the result o this? My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated... *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend jweekend_for...@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_for...@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
Re: Uppercasing inputs
Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: So what's the result o this? My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated... *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend jweekend_for...@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_for...@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.
Re: Uppercasing inputs
if you want the users to have to enter the uppercase then use a validator, if you want to uppercase for them then override getinput() on the textfield and perform the uppercasing there. -igor On Thu, Mar 5, 2009 at 9:46 AM, Peter Ertl 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 jweekend_for...@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_for...@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,
Re: Uppercasing inputs
Due to the mind-boggling complexity of this issue I wrote an open source library 'upstring.jar' which provides plenty of useful stuff... example classes and methods... - class UpperCaseString - class LowerCaseString - class InitialUpperCaseWithRemainingLowerCaseString - class CamelCaseString - class UpperCaseAtPositionString(int firstIndex, int lastIndex) - UpperCaseDecorator(String original) - UpperCaseProvider.getUpperCaseInstance(Locale locale) - UpperCaseUtil.countUpperCaseChars(Object arg) Am 05.03.2009 um 19:01 schrieb jWeekend: Dear Software House, We realise that our requirement is very demanding and challenging but we are not used to such honestly; we usually have to pay for several man years of a team of top software experts before they discover that they cannot deliver a solution to our problem. As a sign of our gratitude and respect for your expert foresight, we would like to engage your services for the next 12 months to provide us with the value of PI, accurate to 3 decimal places, as long as you are willing to explain the algorithm to our president who has been wondering why this is not the same as 22/7 since he was kicked out of school at the age of 15 for beating up his Ethics teacher, despite being quite good at mathematics. Your Grateful Customer Peter Ertl-3 wrote: So what's the result o this? My dear customer, actually it is not possible to upper-case your input because type conversion doesn't fit, validation is the wrong place,too, and javascript uppercasing is not reliable if javascript is disabled. However we can compute the 100.000.000 digit of pi but uppercase is too complicated... *g* Am 05.03.2009 um 17:46 schrieb jWeekend: Igor, anyways, just letting you know the intention behind the converters in wicket. OK - that's exactly the thing that needs to be crystal clear. So the bottom line is that the if in your scenario the user entering lower case strings is acceptable then, in Wicket, the conversion to upper- case is not a job for IConverter and something downstream should take care of a the transformation to upper case (within Wicket or further down). If the user input should not even be submitted unless it is in upper case, then use http://www.nabble.com/Re%3A-Uppercasing-inputs- p22332471.html Adriano's solution or something that has a similar effect. Is that summary correct? Regards - Cemal http://jWeekend.om jWeekend igor.vaynberg wrote: On Thu, Mar 5, 2009 at 8:12 AM, jWeekend jweekend_for...@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
Re: Uppercasing inputs
Could there be any unexpected consequences when just up-casing the
string in the model's setter (setObject(...)) ?
like this...
void setObject(String input)
{
this.value = (input != null) ? input.toUpperCase() : null;
}
Am 05.03.2009 um 19:39 schrieb jWeekend:
Leszek,
Thank you asking such a deep question ;-)
We may not all agree, but in the end, at least you have been offered
around
87 well-intentioned solutions you can ask your customer to choose
from; that
will teach them to request such complex features and fuctionality!
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22357806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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 igor.vaynb...@gmail.comwrote: 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 jweekend_for...@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_for...@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
Re: Uppercasing inputs
public class UpperCaseBehavior extends AttributeAppender
{
private static final long serialVersionUID = 1L;
public UpperCaseBehavior()
{
super(style, new ModelString(text-transform: uppercase), ;);
}
@Override
public void bind(Component component)
{
super.bind(component);
component.add(new AttributeAppender(
onkeyup, new ModelString(this.value =
this.value.toUpperCase()), ;));
}
}
Leszek Gawron escreveu:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased before being written to the model?
my regards
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Maybe:
class MyUpperCaseModel extends WhatEverModelString {
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModelString.
Ernesto
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron lgaw...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Leszek,
... or, probably the most Wicket-way of doing this is to make a TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
RE: Uppercasing inputs
Ernesto's got you on the right track. I'd recommend taking it a step further
like described here:
http://www.jeremythomerson.com/blog/2008/11/06/wicket-the-power-of-nested-models/
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: Ernesto Reinaldo Barreiro reier...@gmail.com
Sent: Wednesday, March 04, 2009 9:43 AM
To: users@wicket.apache.org
Subject: Re: Uppercasing inputs
Maybe:
class MyUpperCaseModel extends WhatEverModelString {
public void setObject(String value) {
if(value != null) {
super.setValue(value.toUpperCase());
} else {
super.setValue(value);
}
}
}
and use MyUpperCaseModel instead of WhatEverModelString.
Ernesto
On Wed, Mar 4, 2009 at 4:30 PM, Leszek Gawron lgaw...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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 jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
pft, you guys!
i would go with the simplest!
class uppercasetextfield extends textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
LOL! Nah - I would just change all the setters on every domain object to
be:
public void setFoo(String foo) {
this.foo = foo == null ? null : foo.toUpperCase();
}
Or, maybe I'd use AOP and build an aspect that could automatically intercept
calls to com.mydomain setters that take a single string argument and do the
upper-casing there!
It's makes me smile to think of how many ways a single thing can be done.
Leszek - you should now definitely have plenty of choices. Pick which feels
best / most comfortable for you!
On Wed, Mar 4, 2009 at 5:22 PM, jWeekend jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22341681.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
Re: Uppercasing inputs
you can create a convertermodel that takes an instance of iconverter
and uses that to convert the values, then you can subclass textfield,
override initmodel() and wrap any model the textfield had with this
one.
that way everyone is happy!
-igor
On Wed, Mar 4, 2009 at 3:29 PM, Jeremy Thomerson
jer...@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 jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/Uppercasing-inputs-tp22332360p22335650.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Re: Uppercasing inputs
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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
Leszek,
... or, probably the most Wicket-way of doing this is to make a
TextField
subclass that overrides getConverter to return your special
IConverter
implementation which performs the capitalisation in its
convertToObject.
Regards - Cemal
http://jWeekend.com jWeekend
Leszek Gawron-2 wrote:
Hello,
one of my customers has this weird requirement that all data
should
be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data
written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased
before being written to the model?
my regards
--
Leszek Gawron
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail:
Re: Uppercasing inputs
sigh, i was being sarcastic. i frankensteined both yours and jeremy's
ideas together into a solution that used both and was needlessly
complex.
-igor
On Wed, Mar 4, 2009 at 3:59 PM, jWeekend jweekend_for...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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 jweekend_for...@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
jweekend_for...@cabouge.comwrote:
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
Re: Uppercasing inputs
Igor,
... hence the ;-)
The point is worth making for others who come across this thread, and, just
as much, in response to some of the other solutions suggested.
I don't think there's any more to be milked out of this thread.
Regards - Cemal
http://jWeekend.com jWeekend
igor.vaynberg wrote:
sigh, i was being sarcastic. i frankensteined both yours and jeremy's
ideas together into a solution that used both and was needlessly
complex.
-igor
On Wed, Mar 4, 2009 at 3:59 PM, jWeekend jweekend_for...@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
jer...@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
jweekend_for...@cabouge.comwrote:
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 textfieldstring {
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
jweekend_for...@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
jweekend_for...@cabouge.comwrote:
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
Re: Uppercasing inputs
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
jer...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Hi
I have to agree with Jeremy. I would change the domain model and in
case i must do it in Wicket I will use I will try to configure a
Listener for a general purpose uppercase behavior
taha
On Thu, Mar 5, 2009 at 7:26 AM, James Carman
jcar...@carmanconsulting.com wrote:
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
jer...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Oh, actually, just for the record, I was kidding about that. That was my
facetious / sarcastic tone that unfortunately doesn't come through all that
well in email (although Igor picked it up). But, more power to you - there
are certainly plenty of options!
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, Mar 4, 2009 at 10:30 PM, taha siddiqi tawushaf...@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
jcar...@carmanconsulting.com wrote:
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
jer...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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
jer...@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 tawushaf...@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
jcar...@carmanconsulting.com wrote:
On Wed, Mar 4, 2009 at 6:29 PM, Jeremy Thomerson
jer...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
A slightly different approach: I would talk with the customer again,
because this is a really stupid (excusez le mot) requirement. I hope you
understand their motivation, possibly some legacy system that depends on
uppercase information? Maybe the problem can be shifted to that legacy
system that uppercases all data read from the database?
Regards,
Dave
Leszek Gawron wrote:
Hello,
one of my customers has this weird requirement that all data should be
input/shown uppercase. I can easily add
input {
text-transform: uppercase;
}
to my css rules, but this does not change the fact that data written
into database will still be case sensitive.
How can I create a behavior for TextField so that the dat is
uppercased before being written to the model?
my regards
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
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 mailli...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Uppercasing inputs
Argh.. and ofcourse, you can uppercase it in your model get/set method.
**
Martin
2009/3/5 Martin Makundi martin.maku...@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 mailli...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
