cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [RT] - XUL revisited....
Date Tue, 06 Apr 2004 22:49:43 GMT
On 06.04.2004 16:36, Sylvain Wallez wrote:

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

Same here.

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

Same here.

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

Not necessarily. For the reason of probably difficult implementation of 
consistent validation client and server side I would resign from client 
side validation.

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

Couldn't this be done with (D)HTML too? At least you would do nothing 
different in XUL then DOM operations - the same as for HTML.

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

Another important difference at least for XUL is it's templating 
mechanism. Supply the data as RDF and the XUL page builds up the form 
itself. This would replace forms-samples-styling.xsl & co. But it would 
not make CForms superfluous. I even see no request/response cycles are 

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



View raw message