--- 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]
