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
