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 increm
--- 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
On Tue, Sep 16, 2008 at 3:11 PM, Dave Newton <[EMAIL PROTECTED]> 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
--- 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: [EMAIL PROTECTED]
For
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.
Pl
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
--- 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 the
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 havin
--- 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 revam
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 <[EMAIL PROTECTED]> wrote:
> I'd like to add a couple of hooks into the client-side, non-Ajax validation
> code to make it easier (
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 calendar
because the validation code is all in one place and had to use do
--- 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
>
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
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
14 matches
Mail list logo
