[Trinidad] Client-Side Validation - Enable 'onchange' validation

[Danny Robinson <da...@gmail.com>]

Guys,

Now we're into 1.0.3, I'd like to enable the inline validation for
'onchange' of an input component.  I'd like to start some discussion on how
we'd achieve this and provide the most flexbility.  The feature is currently
implemented in a private method and can be tested using
onchange="_validateInput(this);".  I'd like to use onchange rather than
onblur so that users can still navigate around the form and validation would
only kick-in when they started editing (ie. changing) an inputs value.

My questions for 1.0.3 are:

Should we use 'onchange' and for event based validation?

... and what's the preferred way to do the event registration?

Would this be the default (or perhaps only) mode for client-side validation?

... and would we provide a per-field way to disable event based validation?

Should c/s validation routines be namespaced (e.g. TrValidator)?

... and should we move away from outputting the validator/convertor arrays
per form and perhaps have input components self register their
validators/convertors?

Your thoughts,

Danny
-- 
Chordiant Software Inc.
www.chordiant.com

Re: [Trinidad] Client-Side Validation - Enable 'onchange' validation

[Blake Sullivan <bl...@oracle.com>]

Adam Winer wrote:
> On 8/22/07, Simon Lessard <si...@gmail.com> wrote:
>   
>> On 8/22/07, Danny Robinson <da...@gmail.com> wrote:
>>     
>>> Guys,
>>>
>>> Now we're into 1.0.3, I'd like to enable the inline validation for
>>>       
>> 'onchange' of an input component.  I'd like to start some discussion on how
>> we'd achieve this and provide the most flexbility.  The feature is currently
>> implemented in a private method and can be tested using
>> onchange="_validateInput(this);".  I'd like to use onchange
>> rather than onblur so that users can still navigate around the form and
>> validation would only kick-in when they started editing (ie. changing) an
>> inputs value.
>>     
>>> My questions for 1.0.3 are:
>>>
>>> Should we use 'onchange' and for event based validation?
>>>       
>> Is onchange even working properly in IE 7?
>>     
>
> IMO, onblur, not onchange, but I could probably be easily swayed.
> I'm not aware of problems on IE7 with onchange (though how the
> JS events bubble is always of interest.)
>   
change events are supposed to bubble, but they don't on IE.

-- Blake

>   
>>> ... and what's the preferred way to do the event registration?
>>>       
>
> The 1.0.3 code has an _addValidator() call now - that'd be a very
> good hook for adding any event registration.
>
>   
>>> Would this be the default (or perhaps only) mode for client-side
>>>       
>> validation?
>>
>> I would say yes for INLINE, but no for ALERT because it would probably be
>> very irritating.
>>     
>
> Only INLINE.  ALERTs not only
>   
>>> ... and would we provide a per-field way to disable event based
>>>       
>> validation?
>>
>> Will be strange, but mostly likely requested by users.
>>     
>
> I don't think so, at least at the start.  I'd be much happier with a
> way to disable event-based validation globally though.
>
>
>   
>>> Should c/s validation routines be namespaced (e.g. TrValidator)?
>>>
>>> ... and should we move away from outputting the validator/convertor arrays
>>> per form and perhaps have input components self register their
>>> validators/convertors?
>>>       
>
> Check out the new code - it's a lot less awful. :)
>
> -- Adam
>
>   
>>> Your thoughts,
>>>
>>> Danny
>>> --
>>> Chordiant Software Inc.
>>> www.chordiant.com
>>>       
>>     

Re: [Trinidad] Client-Side Validation - Enable 'onchange' validation

[Adam Winer <aw...@gmail.com>]

On 8/22/07, Simon Lessard <si...@gmail.com> wrote:
>
>
> On 8/22/07, Danny Robinson <da...@gmail.com> wrote:
> > Guys,
> >
> > Now we're into 1.0.3, I'd like to enable the inline validation for
> 'onchange' of an input component.  I'd like to start some discussion on how
> we'd achieve this and provide the most flexbility.  The feature is currently
> implemented in a private method and can be tested using
> onchange="_validateInput(this);".  I'd like to use onchange
> rather than onblur so that users can still navigate around the form and
> validation would only kick-in when they started editing (ie. changing) an
> inputs value.
> >
> > My questions for 1.0.3 are:
> >
> > Should we use 'onchange' and for event based validation?
>
> Is onchange even working properly in IE 7?

IMO, onblur, not onchange, but I could probably be easily swayed.
I'm not aware of problems on IE7 with onchange (though how the
JS events bubble is always of interest.)

> > ... and what's the preferred way to do the event registration?

The 1.0.3 code has an _addValidator() call now - that'd be a very
good hook for adding any event registration.

> > Would this be the default (or perhaps only) mode for client-side
> validation?
>
> I would say yes for INLINE, but no for ALERT because it would probably be
> very irritating.

Only INLINE.  ALERTs not only
>
> > ... and would we provide a per-field way to disable event based
> validation?
>
> Will be strange, but mostly likely requested by users.

I don't think so, at least at the start.  I'd be much happier with a
way to disable event-based validation globally though.


> > Should c/s validation routines be namespaced (e.g. TrValidator)?
> >
> > ... and should we move away from outputting the validator/convertor arrays
> > per form and perhaps have input components self register their
> > validators/convertors?

Check out the new code - it's a lot less awful. :)

-- Adam

> >
> > Your thoughts,
> >
> > Danny
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
>
>

Re: [Trinidad] Client-Side Validation - Enable 'onchange' validation

[Simon Lessard <si...@gmail.com>]

On 8/22/07, Danny Robinson <da...@gmail.com> wrote:
>
> Guys,
>
> Now we're into 1.0.3, I'd like to enable the inline validation for
> 'onchange' of an input component.  I'd like to start some discussion on how
> we'd achieve this and provide the most flexbility.  The feature is currently
> implemented in a private method and can be tested using
> onchange="_validateInput(this);".  I'd like to use onchange rather than
> onblur so that users can still navigate around the form and validation would
> only kick-in when they started editing (ie. changing) an inputs value.
>
> My questions for 1.0.3 are:
>
> Should we use 'onchange' and for event based validation?


Is onchange even working properly in IE 7?

... and what's the preferred way to do the event registration?
>
> Would this be the default (or perhaps only) mode for client-side
> validation?


I would say yes for INLINE, but no for ALERT because it would probably be
very irritating.

... and would we provide a per-field way to disable event based validation?


Will be strange, but mostly likely requested by users.

Should c/s validation routines be namespaced (e.g. TrValidator)?
>
> ... and should we move away from outputting the validator/convertor arrays
> per form and perhaps have input components self register their
> validators/convertors?
>
> Your thoughts,
>
> Danny
> --
> Chordiant Software Inc.
> www.chordiant.com