Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "Christofer Dutz" <christofer.dutz@c-ware.de>
To: <dev@cocoon.apache.org>
References: <DCBD3690-7713-42BD-B484-27893BF7B976@apache.org>
In-Reply-To: <DCBD3690-7713-42BD-B484-27893BF7B976@apache.org>
Subject: AW: Client-side validation in CForms
Date: Sun, 13 Jul 2008 14:13:12 +0200
Message-ID: <00ed01c8e4e1$d2bb3d80$7831b880$@dutz@c-ware.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acjh1tkAcV8Qr9XQSvirbebQfjcJXADCiA7A
Content-Language: de

When I was working on my first attempts to do exactly what you are =
trying to
do (CForms using dojo 1.1 and client side validation), I ran into =
exactly
the same problem as you did. I too think it would be easily possible to
implement client and server-side validation using dojo. Even if it would =
not
be possible to implement all.=20

Unfortunately the fi-output is hard-coded into the widget class
implementation and no validation information is sent. Making client-side
validation work, it would make it necessary to patch every single Widget
class to output this validation-data, but should be easy to accomplish.

I stopped my work on this, since I had doubt's anyone would be =
interested in
a feature like this and the thought of having to maintain patches for so
many classes let me drop that idea.

Chris


-----Urspr=FCngliche Nachricht-----
Von: Jeremy Quinn [mailto:jeremy@apache.org]=20
Gesendet: Mittwoch, 9. Juli 2008 17:17
An: dev@cocoon.apache.org
Betreff: Client-side validation in CForms

Hi All

As you may know, I am working heavily on the revamp of Dojo on the =20
client-side of CForms.

In Dojo it is possible to perform quite a lot of validation on form =20
fields. There is a partial match between the validation capabilities =20
of CForms and those of Dojo. Several people have thought in the past =20
that it would be good to have the same validation occur on both the =20
server and the client.

OTTOMH, the kind of validators we could probably make work in both =20
places would be :
	email, length, mod10, range and regexp (plus maybe javascript, if we

can sort out any context differences)

ATM however, no validation information is output by the form =20
generation process. Datatypes are there (which I can initially use) =20
but no validation.

So my question is, would someone volunteer to either add the =20
definition's validation tags to the output or help work out the =20
cleanest approach to adding it?

Many thanks


regards Jeremy