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, 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 >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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-tp22332360p22355520.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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
