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.com>wrote: >>>>>> >>>>>>> >>>>>>> Igor, >>>>>>> >>>>>>> Nope, not for me (this time). >>>>>>> Here's the Javadoc for updateModel: >>>>>>> * Updates this components model from the request, it expects >>>>>>> that >>>>>>> the >>>>>>> object is already >>>>>>> * converted through the convertInput() call that is called by >>>>>>> the >>>>>>> validate() method when a form >>>>>>> * is being processed. >>>>>>> >>>>>>> Regards - Cemal >>>>>>> http://jWeekend.com jWeekend >>>>>>> >>>>>>> >>>>>>> igor.vaynberg wrote: >>>>>>> > >>>>>>> > pft, you guys! >>>>>>> > >>>>>>> > i would go with the simplest! >>>>>>> > >>>>>>> > class uppercasetextfield extends textfield<string> { >>>>>>> > public void updatemodel() >>>>>>> > { >>>>>>> > final String str=getconvertedinput(); >>>>>>> > >>>>>>> setdefaultmodelobject((str==null)?null:str.touppercase()); >>>>>>> > } >>>>>>> > } >>>>>>> > >>>>>>> > done! >>>>>>> > >>>>>>> > -igor >>>>>>> > >>>>>>> > On Wed, Mar 4, 2009 at 3:07 PM, jWeekend >>>>>>> <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.com>wrote: >>>>>>> >>> >>>>>>> >>>> >>>>>>> >>>> Leszek, >>>>>>> >>>> >>>>>>> >>>> ... or, probably the most "Wicket-way" of doing this is to make >>>>>>> a >>>>>>> >>>> TextField >>>>>>> >>>> subclass that overrides getConverter to return your special >>>>>>> IConverter >>>>>>> >>>> implementation which performs the capitalisation in its >>>>>>> >>>> convertToObject. >>>>>>> >>>> >>>>>>> >>>> Regards - Cemal >>>>>>> >>>> http://jWeekend.com jWeekend >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> Leszek Gawron-2 wrote: >>>>>>> >>>> > >>>>>>> >>>> > Hello, >>>>>>> >>>> > >>>>>>> >>>> > one of my customers has this weird requirement that all data >>>>>>> should >>>>>>> >>>> be >>>>>>> >>>> > input/shown uppercase. I can easily add >>>>>>> >>>> > >>>>>>> >>>> > input { >>>>>>> >>>> > text-transform: uppercase; >>>>>>> >>>> > } >>>>>>> >>>> > >>>>>>> >>>> > to my css rules, but this does not change the fact that data >>>>>>> written >>>>>>> >>>> > into database will still be case sensitive. >>>>>>> >>>> > >>>>>>> >>>> > How can I create a behavior for TextField so that the dat is >>>>>>> >>>> uppercased >>>>>>> >>>> > before being written to the model? >>>>>>> >>>> > >>>>>>> >>>> > my regards >>>>>>> >>>> > >>>>>>> >>>> > -- >>>>>>> >>>> > Leszek Gawron >>>>>>> >>>> > >>>>>>> >>>> > >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>> > To unsubscribe, e-mail: users-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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeremy Thomerson >>>>>> http://www.wickettraining.com >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Become a Wicket expert, learn from the best: http://wicketinaction.com >>>> Apache Wicket 1.3.5 is released >>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-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-tp22332360p22347989.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-tp22332360p22354741.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 > > -- Marcelo Morales --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
