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

Reply via email to