cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: XULifying CForms (yet another attempt?)
Date Mon, 10 Oct 2005 16:57:03 GMT
On 10/10/05, Joerg Heinicke <> wrote:
> Gianugo Rabellino <gianugo <at>> writes:
> > 1. server roundtrip model: Xul doesn't really fit in a
> > request-response model where all data travel at once upon hitting a
> > submit button. This might lead to two different alternatives: (a) ajax
> > all over the place, where more or less every widget submits events to
> > a Cocoon server or (b) server roundtrips being avoided whenever
> > possible thanks to the richest functionalities of a Xul frontend
> > (think repeaters).
> Is it an either-or-decision?

Well, the way I see it is that either the Xul incarnation of CForms
provides a different roundtrip model for client-server communication
or it would "just" be a 1:1 mapping to the current HTML forms. Not
much added value compared to an HTML rendering, given it would still
be browser based *and* strongly tied to just one browser. Why should
anyone choose to use the Xul version nowadays then?

> > Convergence with the new Ajax model of CForms
> > somewhat blurs the line, yet I feel that a mere translation of CForms
> > widgets to Xul without a rethink of the roundtrip model might be
> > somewhat limiting (as in "uh, ok, so what?").  Actually, I might go as
> > far as saying that the whole Xul/CForms marriage might not have that
> > much sense now that we have Ajax and all the Web 2.0 yadda-yadda. That
> > is, unless we figure out some real advantage in server interaction.
> Claas and I came to the conclusion that Ajax as-is does not work with XUL.

If you mean as-is as the current Cocoon incarnation, I don't quite see
why, apart from some tweaks that might be necessary. The whole idea of
Ajax actually was in Xul since day one, given that manipulation of the
widget tree is delegated to javascript and network communication has
to happen through XmlHttpRequest. And I have the perception that XBL
might play a role even here

> > 2. the role of XBL. I feel XBL (xul binding/extension language) might
> > play an important role in producing advanced widgets (again, think
> > repeaters, calendar popups, double selection lists... well, you name
> > it). Still, XBL is tightly coupled with CSS, and I'm not sure how to
> > manage the CSS->XBL relationship within Cocoon.
> That's really advanced stuff. Starting with simple stuff will be hard enough ;)

Hmm... point is I'm afraid you won't go much farther than a few text
input, checkboxes, radios and selection lists without XBL...

> Breaking the ice might be necessary :) Wait for the code submit and the status I
> will send.

Sure thing, looking forward to it!

Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:
(blogging at

View raw message