Zachary, I will definitely find your code that does client-side
validation useful. I don't know if this helps but Jeremy Thomerson had
a presentation on custom JavaScript integration with Wicket
(http://stuq.nl/weblog/2009-11-27/london-wicket-meetup-wicket-1-5-wiquery-brix-and-more).

On Mon, Feb 20, 2012 at 2:06 PM, Maarten Bosteels
<mbosteels....@gmail.com> wrote:
> On Wed, Feb 15, 2012 at 5:41 PM, Paul Jackson <paul.jack...@cdl.co.uk>wrote:
>
>> We do something very similar to this, and agree that it works really
>> well. We also use JSR303 annotations on our domain models and use them
>> to drive adding both wicket and jquery validators.
>>
>> We have a bunch of ValdiationConfiguration classes that know what to add
>> to the markup and javascript to get the client side validation to work,
>> so we don't need an extension to IValidator.
>>
>> Cheers,
>> Paul
>>
>> -----Original Message-----
>> From: Zachary Bedell [mailto:zacl...@thebedells.org]
>> Sent: 15 February 2012 15:52
>> To: users@wicket.apache.org
>> Subject: Wicket jQuery Validator integration
>>
>> Good morning,
>>
>> Reading a recent thread about accessing jQuery Validation from Wicket
>> reminded me that I've developed some code that might be of use.  I'm not
>> sure if this is something anyone else would be interested in or if it's
>> something that might eventually be integrated into Wicket core or if it
>> would be more appropriate for one of the existing jQuery/Wicket
>> integration libraries.  I wanted to describe what I've cooked up so far.
>> If this is anything that would be useful, I'd be willing to clean the
>> code up a bit to extract a few bits that are specific to our environment
>> and post the code somewhere.
>>
>> My intent was to get client-side validation using Wicket's existing
>> validation classes without requiring AJAX calls to make them work and
>> preferably without requiring Page's to include lots of unsightly
>> JavaScript.  Also, not duplicating validation logic on the client &
>> server tiers was desirable.  The code was originally developed for a
>> site that was expected to receive a high amount of traffic in a short
>> period of time, and avoiding unnecessary server calls was a priority.
>>
>> I created a subclass of Form (ClientSideValidatingForm) which examines
>> each FormComponent (and sub-Form) added to it and extracts information
>> about the standard Wicket validations.  It generates JavaScript which
>> uses jQuery's Validator library to apply client-side checks equivalent
>> to the Wicket server side checks.  The nice thing about this is that you
>> get client-side validation for "free" just by adding the normal Wicket
>> validations plus you still get all your validations backed up in the
>> server side in case JavaScript is unavailable or disabled.
>>
>> The implementation of the class does lack a bit in terms of elegance
>> unfortunately.  As the Wicket validation interface doesn't currently
>> know anything about JavaScript, it was necessary to run a chain of
>> instanceof checks against all the known Wicket validations and emit
>> JavaScript to mirror their logic.  I also created an extension of the
>> Wicket IValidator interface which can provide JavaScript functions to
>> perform validation equivalent to the server-side Java code.  The
>> extraction code in ClientSideValidatingForm preferentially checks for
>> this interface and uses provided JavaScript if available.  Otherwise,
>> it's a bunch of instanceof's to check for known validations or log an
>> error if an unknown instance of IValidator is found.
>>
>> Long term, it would be helpful if the stock Wicket IValidator interface
>> could include a method to get JavaScript validations for all of the
>> stock validations.
>>
>> The code is pretty tightly bound to jQuery Validator at this point, but
>> it's likely the methodology could be abstracted to other validation
>> frameworks.  It's also built using WiQuery, though that's mostly as a
>> convenience to get the same version of jQuery that we use elsewhere.
>> The same could easily be implemented without WiQuery provided a version
>> of jQuery was contributed to the response via some other mechanism.
>>
>> Is this something anyone would be interested in?
>>
>
>
> yes ;-)
>
>
>>
>> Best regards,
>> Zac Bedell
>>
>> (Apologies if this is a dupe. I had some email client config issues this
>> morning...)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>> **********************************************************************
>> Please consider the environment - do you really need to print this email?
>>
>> This email is intended only for the person(s) named above and may contain
>> private and confidential information. If it has come to you in error,
>> please destroy and permanently delete any copy in your possession and
>> contact us on +44 (0) 161 480 4420. The information in this email is
>> copyright © CDL Group Holdings Limited. We cannot accept any liability for
>> any loss or damage sustained as a result of software viruses. It is your
>> responsibility to carry out such virus checking as is necessary before
>> opening any attachment.
>>
>> Cheshire Datasystems Limited uses software which automatically screens
>> incoming emails for inappropriate content and attachments. If the software
>> identifies such content or attachment, the email will be forwarded to our
>> Technology Department for checking. You should be aware that any email
>> which you send to Cheshire Datasystems Limited is subject to this procedure.
>>
>> Cheshire Datasystems Limited, Strata House, Kings Reach Road, Stockport
>> SK4 2HD
>> Registered in England and Wales with Company Number 3991057
>> VAT registration: 727 1188 33
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to