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