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
