Adam Winer wrote:
On 8/22/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
On 8/22/07, Danny Robinson <[EMAIL PROTECTED]> 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
