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.
Agree.
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 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).
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)
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.
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
