cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] - XUL revisited....
Date Tue, 06 Apr 2004 14:36:53 GMT
Bruno Dumon wrote:

>I'm wondering though what the value of this is.
>The main advantage of CForms is to handle the typical problem of HTML
>forms: the form needs to be redisplayed in a loop until everything's
>valid. This is because the browser is a stupid client which we need to
>send a new page after each interaction.


>If you're developing a smarter client using XUL or Flash, you're not
>likely going to send a new XUL file or Flash movie to the browser
>between each interaction. Rather, all validation logic (and event
>handling logic) can be implemented in the client, which can communicate
>XML messages with the server. Somehow forcing CForms in between there
>seems unnatural to me.

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 
- 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).

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 

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)

The main difference between XUL/Flash and HTML, however, is that 
XUL/Flash can consume XML streams. We therefore can use CForms, but the 
pipeline for producing the form will be different, as it can be limited 
to the form data (i.e. the output of the FormsGenerator) rather than a 
page layout filled with valued widgets.

So IMO, CForms still makes sense with XUL & Flash.



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message