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.
musachy On Sat, Sep 6, 2008 at 11:42 PM, Dave Newton <[EMAIL PROTECTED]> 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
