Dave that would be a very useful addition! A few days ago I managed to include a basic client side DateValidator in my slightly modified xhtml theme, but the experience was far from ideal. The validator only worked for the <datetimepicker> calendar because the validation code is all in one place and had to use dojo specific calls to get the values I needed.
It would be good that the client side validation code be refactored so that validation routines are independent of the particular theme/component. Also field error detection separate from how the error will be shown by a particular theme. And validation routines separate of how to get the value from the particular component. 2008/9/7 Dave Newton <[EMAIL PROTECTED]>: > --- On Sun, 9/7/08, Musachy Barroso wrote: >> who would be responsible for showing the errors? if it is >> the framework, then an error map needs to be returned, like >> you said. If it is the plugged in functions, then we need to >> document those utility functions that we have to show validation >> errors. I like the idea. > > I think the existing addError() function could have some additional > functionality to either use a callback into user code (my preference, but I'm > very comfortable with JavaScript) or to put it into a collection. > > Maybe put it into a collection then do the callback if it exists, otherwise > look for a known-named UL in which to put them, I dunno. A client-side > fielderrors-like tag could create that. > > Dave > >> On Sat, Sep 6, 2008 at 11:42 PM, Dave Newton wrote: >> > I'd like to add a couple of hooks into the >> client-side, non-Ajax validation >> > code to make it easier (possible?) to call custom >> JavaScript validators. My >> > current solution seems a bit stop-gappy, but >> ultimately might be flexible >> > enough to suffice. >> > >> > ObCaveat: I've only looked at the >> "xhtml" theme so far; other themes may >> > have different requirements than my current >> implementation supports. >> > >> > Right now my idea is to register, via JS, custom >> validators into an >> > S2-specific JS module. The JS in >> form-close-validate.ftl, after running its >> > existing code, would check to see if any validators >> have been registered and >> > if so, iterate over and call them. >> "Registration" could be as simple as >> > putting a map of JS functions in a known spot; >> whatever. (A registration >> > process seems more... official?) >> > >> > The validation function receives the form element. >> Other than that it's >> > completely responsible for doing its >> thing--there's no connection to the >> > server-side config at all (hence stop-gappy). My >> current code just returns >> > "true" if there's a validation error, >> but should return a map/etc. that also >> > contains a continueValidation value. >> > >> > (I'd also kinda like to be able to give each >> validator a set of >> > messages--this way the validator proper could live in >> a .js file but get >> > messages from a .jsp via <s:text.../>. A simple >> regexp-based JS utility >> > method can be used to do parameter replacement from >> the JS validator. This >> > could probably be done without involving the >> framework, though; haven't >> > thought about it yet.) >> > >> > The validator can use the existing addError() function >> (which I'd rather >> > see in an S2 module). Ideally the >> <s:fielderror.../) tag, or a client-side >> > equivalent, could be used as a container with an >> unordered list, filled with >> > the messages and un-hidden on errors. Or the user can >> register a callback >> > for adding messages and addError could defer to that >> if present or call it >> > in addition to the existing code, or whatever. >> > >> > Thoughts, improvements, objections, ...? >> > >> > Thanks, >> > Dave >> > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> > >> > >> >> >> -- >> "Hey you! Would you help me to carry the stone?" >> Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
