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.)
