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. 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 > > > -- View this message in context: http://www.nabble.com/Uppercasing-inputs-tp22332360p22357058.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
