Nice; I'll get to using that. I guess all that's missing is a way to
register an onAfterCheck type event handler. :)
On Dec 8, 1:58 pm, "Jörn Zaefferer" <[EMAIL PROTECTED]>
wrote:
> Thanks for the feedback. I agree that post-validation events make more
> sense. The seperation of validation and message display is partially
> in place - you can already use the showErrors-option to fully override
> the message display.
>
> In the meantime, here's a workaround:
>
> var validator = $(...).validate();
> var check = validator.check;
> validator.check = function(element) {
> var result = check.apply(this, arguments);
> // do something after validating an element, use element and result
> variables
> return result;
>
> });
>
> Jörn
>
> On Mon, Dec 8, 2008 at 7:20 PM, Mihai Danila <[EMAIL PROTECTED]> wrote:
>
> > 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.)
