Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Gabriel Belingueres <be...@gmail.com>]

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 <ne...@yahoo.com>:
> --- 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:
>> dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail:
>> dev-help@struts.apache.org
>> >
>> >
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?"
>> Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

--- 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:
> dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> dev-help@struts.apache.org
> >
> >
> 
> 
> -- 
> "Hey you! Would you help me to carry the stone?"
> Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Musachy Barroso <mu...@gmail.com>]

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 <ne...@yahoo.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

--- On Tue, 9/16/08, Gabriel Belingueres wrote:
> Switching to commons-validator because of its javascript code only?

No. The thread contains the original issue and comments.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Gabriel Belingueres <be...@gmail.com>]

Switching to commons-validator because of its javascript code only?
Would it be imprudent just grab the js code without adding
commons-validator as a dependency?
Last time I checked seemed as if commons-validator was kind of
dormant. Still, seems like it is the lowest resistance path to follow.

Please let me know if I can provide you any assistance for this improvement.

2008/9/16 Dave Newton <ne...@yahoo.com>:
> Any more comments?
>
> The question has come up a few times on the user list in the last week or two. My proposal is an incremental improvement (if tiny); if we switch to commons-validator at least their JavaScript code could be re-used.
>
> Dave
>
> --- On Wed, 9/10/08, Dave Newton wrote:
>> --- On Tue, 9/9/08, Jeromy Evans wrote:
>> > I don't use S2's client-side validation myself
>> as its too fragile, and
>> > this improvement won't help that. (fragile as in
>> its hardcoded to match
>> > a theme's tag structure and breaks if a tag is
>> out-of-place).
>>
>> I was also going to add some ids here and there, mostly for
>> styling purposes, but the label-finding code would also be
>> much-simplified and a tad more resilient.
>>
>> But the primary motivation was to allow a way of adding
>> more client-side validations w/o a major undertaking. I know
>> it's kinda hacky.
>>
>> Dave
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

--- On Tue, 9/16/08, Niall Pemberton wrote:
> IMO the commons validator javascript is pretty horrible -
> each validator assumes there is a method named after the 
> form which returns an array [...]

The original issue wasn't the JavaScript validation code itself, it was the inability to plug in *additional* custom client-side validations.

There's no way to tie server-side validation configuration to client-side JavaScript methods (that I know of). My goal was simply to provide a way to define JavaScript validations on a page-by-page basis and have the existing validation code look for, and call, those validations if any were detected.

I just want a stop-gap measure to provide an easy answer to the common need of adding different client-side validations to "fill the void" between now and whenever/ifever the existing XWork validation framework is revamped to provide this kind of functionality.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Niall Pemberton <ni...@gmail.com>]

On Tue, Sep 16, 2008 at 3:11 PM, Dave Newton <ne...@yahoo.com> wrote:
> Any more comments?
>
> The question has come up a few times on the user list in the last week or two. My proposal is an incremental improvement (if tiny); if we switch to commons-validator at least their JavaScript code could be re-used.

IMO the commons validator javascript is pretty horrible - each
validator assumes there is a method named after the form which returns
an array of the fields to be validated, error message and options and
the validation method then goes through the returned array processing
each field and validating. Its a pretty crap architecture, results in
fields being evaluated by validation type (rather than their natural
order) and is unuseable without something to generate the method that
returns the array (which the Struts1 form tag does from memory).

http://svn.apache.org/repos/asf/commons/proper/validator/trunk/src/javascript/org/apache/commons/validator/javascript/

I think at best you can salvage some code - but its far from being in
a useable state. I had plans a long time ago to refactor it and
produced a prototype - but never got round to finishing it and
committing it back. Might be a better place to start though. Code and
info available here:

http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html

Also related Commons JIRA ticket is here:
http://issues.apache.org/jira/browse/VALIDATOR-106

Probably (if you are interested) then just want to pull out the
JavaScript files.

Niall


> Dave
>
> --- On Wed, 9/10/08, Dave Newton wrote:
>> --- On Tue, 9/9/08, Jeromy Evans wrote:
>> > I don't use S2's client-side validation myself
>> as its too fragile, and
>> > this improvement won't help that. (fragile as in
>> its hardcoded to match
>> > a theme's tag structure and breaks if a tag is
>> out-of-place).
>>
>> I was also going to add some ids here and there, mostly for
>> styling purposes, but the label-finding code would also be
>> much-simplified and a tad more resilient.
>>
>> But the primary motivation was to allow a way of adding
>> more client-side validations w/o a major undertaking. I know
>> it's kinda hacky.
>>
>> Dave
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Jeromy Evans <je...@blueskyminds.com.au>]

Dave Newton wrote:
> Any more comments?
>
> The question has come up a few times on the user list in the last week or two. My proposal is an incremental improvement (if tiny); if we switch to commons-validator at least their JavaScript code could be re-used.
>
> Dave
>   

I still say go with the incremental improvement as you propose.

One day, in the not too distant future, I predict someone will have the 
inclination to create a new tag template with a new client-side 
validator.  In the mean-time, your fix is useful for the poor souls that 
have to cope with the existing code.





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

Any more comments?

The question has come up a few times on the user list in the last week or two. My proposal is an incremental improvement (if tiny); if we switch to commons-validator at least their JavaScript code could be re-used.

Dave

--- On Wed, 9/10/08, Dave Newton wrote:
> --- On Tue, 9/9/08, Jeromy Evans wrote:
> > I don't use S2's client-side validation myself
> as its too fragile, and 
> > this improvement won't help that. (fragile as in
> its hardcoded to match 
> > a theme's tag structure and breaks if a tag is
> out-of-place).
> 
> I was also going to add some ids here and there, mostly for
> styling purposes, but the label-finding code would also be
> much-simplified and a tad more resilient.
> 
> But the primary motivation was to allow a way of adding
> more client-side validations w/o a major undertaking. I know
> it's kinda hacky.
> 
> Dave
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

--- On Tue, 9/9/08, Jeromy Evans wrote:
> I don't use S2's client-side validation myself as its too fragile, and 
> this improvement won't help that. (fragile as in its hardcoded to match 
> a theme's tag structure and breaks if a tag is out-of-place).

I was also going to add some ids here and there, mostly for styling purposes, but the label-finding code would also be much-simplified and a tad more resilient.

But the primary motivation was to allow a way of adding more client-side validations w/o a major undertaking. I know it's kinda hacky.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Jeromy Evans <je...@blueskyminds.com.au>]

Dave Newton wrote:
> --- On Tue, 9/9/08, Martin Cooper wrote:
>   
>> This smells like reinventing a subset of Commons Validator
>> just for S2. Can you convince me otherwise?
>>     
>
> My initial motivation was to create a stop-gap, extensible mechanism for adding custom JavaScript validators without having to do a major XW/S2 revamp. The current mechanism doesn't really provide any support for that; my solution was 10-20 lines of JavaScript.
>   

A small improvement to the existing validator is better than doing nothing.

I'd like to see a move to Commons Validator, but that'll require a new 
theme, which should really use new tags, which should really use GXP 
instead of FTL, and so on; resulting in further stagnation.

I don't use S2's client-side validation myself as its too fragile, and 
this improvement won't help that. (fragile as in its hardcoded to match 
a theme's tag structure and breaks if a tag is out-of-place).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Dave Newton <ne...@yahoo.com>]

--- On Tue, 9/9/08, Martin Cooper wrote:
> This smells like reinventing a subset of Commons Validator
> just for S2. Can you convince me otherwise?

My initial motivation was to create a stop-gap, extensible mechanism for adding custom JavaScript validators without having to do a major XW/S2 revamp. The current mechanism doesn't really provide any support for that; my solution was 10-20 lines of JavaScript.

There was discussion some time back about re-vamping XWork's validation; I don't know what the end result of that conversation was. If there's a reasonable way to specify JavaScript validation methods in the XWork config I'd prefer that. For example, if we could pass a param to the field validators, whatever, that's fine.

If the answer is to create a commons-validator mechanism for S2, that's fine too (as long as I don't have to put my JavaScript in an XML file), although I don't know what the cost of adding OGNL support to the messages would be. I'd guess they could be evaluated against the stack.

Dave


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Client-side validation extensions

[Martin Cooper <ma...@apache.org>]

This smells like reinventing a subset of Commons Validator just for S2. Can
you convince me otherwise?

--
Martin Cooper


On Sat, Sep 6, 2008 at 8:42 PM, Dave Newton <ne...@yahoo.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>