cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [RT] - XUL revisited....
Date Tue, 06 Apr 2004 15:53:08 GMT
On Tue, 2004-04-06 at 16:36, Sylvain Wallez wrote:
> >
> Don't agree ;-)
> One area where CForms can (and must) improve is client-side validation. 
> This has already been discussed, maybe it's time to consider 
> implementing it.
> If we look at the elements composing a Form, some of them can be handled 
> client-side:
> - datatypes (is it a correct int? is this date format correct?)
> - validators (only those that act on the widget's value and do not 
> require access to server-side data).

I've previously thought a bit about the above points and I always got
stuck on how to implement exactly the same behaviour client-side and
server-side. If we don't do that, it's possible to wind up in the
situation where the client says something is invalid while the server
would accept it and vice versa.

For example currently the server side number and date parsing is based
on the Java classes from the java.text package, which allow for advanced
format specifications. Maybe instead we should implement our own limited
ones so that we can use exactly the same algorithms client and server

Or maybe I'm just making it too complex ;-)

> If we look at the different client-side scripting technologies, all rely 
> on JavaScript (or a dialect thereof in the case of Flash). So it is 
> perfectly feasible for some (but not all) datatypes and validators to be 
> able to produce a JavaScript snippet that would do client-side the job 
> they already do server-side. That JS snippet would rely on a client-side 
> JS library which can have different implementations for HTML, XUL and 
> ActionScript.
> This allows to minimize the number of loops on all clients.
> On XUL/Flash clients, the number of loops can also be furthermore 
> reduced by e.g. handling row actions client-side (add/delete rows). But 
> even in that case, we cannot totally get rid of the loop since there is 
> some application-related validation or event handlers (e.g. carselector)

Ideally when using XUL I'd also implement the carselector completely
client side, performing HTTP requests from javascript to retrieve the
new selection list data.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message