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 <[email protected]> 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
>> <[email protected]> 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
>>> <[email protected]>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 <[email protected]>
>>>> > 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
>>>> >>> <[email protected]>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: [email protected]
>>>> >>>> > For additional commands, e-mail: [email protected]
>>>> >>>> >
>>>> >>>> >
>>>> >>>> >
>>>> >>>>
>>>> >>>> --
>>>> >>>> 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: [email protected]
>>>> >>>> For additional commands, e-mail: [email protected]
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> --
>>>> >> 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: [email protected]
>>>> >> For additional commands, e-mail: [email protected]
>>>> >>
>>>> >>
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: [email protected]
>>>> > For additional commands, e-mail: [email protected]
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>> --
>>> Jeremy Thomerson
>>> http://www.wickettraining.com
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>
> --
> View this message in context: 
> http://www.nabble.com/Uppercasing-inputs-tp22332360p22342462.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to