Hi Jörn, I've put together some simplified example pages showing the two main use cases I'm having a problem with. I created two versions of each page, one using Validate 1.1.2, and one using Validate 1.2.1. The 1.1.2 example function properly, while the 1.2.1 versions don't.
Validating a subsection of a larger form: http://www.gearheadsoftware.com/subsect-112.html http://www.gearheadsoftware.com/subsect-121.html Dynamically setting up validation for editable table rows: http://www.gearheadsoftware.com/tableval-112.html http://www.gearheadsoftware.com/tableval-121.html I put a bit of explanatory text in the test pages, but I can provide more detail, if needed. These examples are adapted from the largest and most important form in the application I'm creating, and thus far, the Validate plugin has been an indispensable tool in creating the UI. I would really like to continue using it to implement the functionality I need, but I have to be able to support these use cases, so I'm willing to put in whatever effort required to make it work. :) Many thanks, Bryce Lohr On Apr 10, 6:23 pm, Jörn Zaefferer <[EMAIL PROTECTED]> wrote: > Bryce Lohr schrieb:> [...] > > If you have any suggestions, or alternate strategies, I'd be quite > > grateful. Also, if solved, would you consider adding the patch back to > > the main distributed version? The added flexibility should be useful > > beyond just my case. > > You are right that the plugin brokebackwardscompability in a few ways, > but so far you are the only one to report this issue. > > It would definitely help if you could provide a few more concrete > examples - I'd like to evaluate if there are viable options to solve > your problem without giving up the form-per-validator design. A key > feature of that is the ability to freely add and remove elements from a > form, without having to care about manully initializing validation for > those or caring about event handlers. > > Jörn
