Igor, You made it very clear why a converter isn't appropriate. And also why you shouldn't use a Validator when you don't want to force the user to enter uppercase.
But what's your opinion about using an UpperCasingModel ? Downside of overriding getInput is that you'd have to do it on TextField, PasswordTextFiled, RequiredTextField, AutoCompleteTextField, ... Or am I missing something ? Maarten On Thu, Mar 5, 2009 at 7:19 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote: > 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 > >
