If the new handlers would want to extend on (be siblings of) the "invalidHandler" feature, then they should be consistent with invalidHandler's behavior. If invalidHandler fires after validation, then that's when the new events should fire.
On a slightly different note, a passive observer may not care when the event fires relative to the validation itself, namely because a passive observer cares if the field "would be considered valid" and not much about what's out there. For observers that intend to make changes, like the one that sets up tooltips, a post validation event makes it easier, as all the markup and data is there to manipulate when the post-validation event fires. A pre-validation event would achieve this reasonably only if it allowed the handler to specify a callback that generates the label, or other such complications. (Note Windows programming has historically provided both pre- and post- events for various processes---recall OnBeforeSave and OnAfterSave--- but that may also be too much.) In general, the more hooks one provides, the better the performance that can be achieved with the framework; our point in case, the tooltip example, indicates that an after- event handler will do work that makes the label generation process superfluous (hence unnecessary work on the part of the validator). I would go ahead and provide the after- event. I'm thinking in the future you'll want to separate the validation from the rendering of the vaidation results and that will make it easier to allow customizations of the rendering (I think there's a note about this separation on your site) but hey, I've only just arrived in both jQuery and Validator workd; you'll get better input on this hot topic from more informed users. Mihai On Dec 8, 11:47 am, "Jörn Zaefferer" <[EMAIL PROTECTED]> wrote: > Currently those field-based validation events are missing. Would you > need an event that is called whenever a field is validated? Before > validation occurs? After it's done? Only when (in)valid? > > There are quite a few potential permutations, I'd like to focus on > those being actually useful. > > Jörn > > On Mon, Dec 8, 2008 at 4:42 PM, Mihai Danila <[EMAIL PROTECTED]> wrote: > > > I have a few questions, given that I'm new to the validation plugin. > > > 1. We validate groups of controls; validation for the entire group > > succeeds if at least one field is present -- call it REQUIRED on > > steroids. To implement this, we use one call to addMethod + one CSS > > class per group of controls. (Is there a better way?) Now assume I > > submit a form containing one such group with three fields, all blank. > > I get three validation messages, one next to each field. So far so > > good. Now assume I enter a value in one of the fields and blur it. How > > can I cause all the remaining fields to validate and have their > > messages disappear? > > > I can cause the fields within a group to validate by placing blur > > events and triggering validate for the entire group of fields. But > > this is costly; what I'm really looking for here is an event from the > > validator that triggers whenever some part of the form is being > > validated. That would be more natural. Is there such an event? > > > 2. I'm trying to put the validation messages in tooltips. Again, I > > miss this validation event to let me scan the form and create the > > tooltips. > > > Is there such a validation event or is it on the TODO list? (Note: The > > invalidHandler function only executes when I try to submit the form, > > not when a control is validated; as such, it doesn't fit the bill.)
