Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gianugo@gmail.com designates
 72.14.204.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=JHpKehdVu8rpdqNkJOWqb0Rnrg4SXcKwmRpmWcsZGxgPnk+dT4y9fPuXx87+sFOjYhDKo02JBpbSpimreRGZJdynWBfcJp9T13pbrGYJl9LJe/fGtb+jSmHhdm8yd1ZAsWZ/HmSMlmnwIdgthTaRH0QRFXBcNdW8n7FohgzGWjo=
Message-ID: <7557e99f0510100801n3835a46nd8496df9c0b8bbb9@mail.gmail.com>
Date: Mon, 10 Oct 2005 17:01:05 +0200
From: Gianugo Rabellino <gianugo@gmail.com>
To: dev@cocoon.apache.org
Subject: XULifying CForms (yet another attempt?)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've been playing quite a bit these days with Xul, after a few years'
hyatus which made me appreciate the comeback even more. :) I'm more
and more inclined in devoting some of my Copious Free Time to a Xul
CForms renderer, and I wanted to catch up with other fellow members
and see what's going on.

I understand from
http://issues.apache.org/bugzilla/show_bug.cgi?id=3D25295 that Jorg is
already doing something, so before reinventing wheels I'd love to know
what the current status is and if/how I might help. So far, I have
identified a few points on my radar:

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

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.

3. HTML orientation of CForms: despite a clear intention to stay as
neutral as possibile, CForms has a strong bias towards HTML in its
most advanced widgets (well, think HTMLarea to see my point). I'm not
sure if it's entirely possible to get rid of the HTML heritage, and I
kinda feel that in some cases it even doesn't make much sense (hey,
after all Xul is happy with xhtml snippets).

Well, these are just a few initial thoughts, which don't even deserve
the status of [RT]: let's say I'm just trying to break the ice and see
what's going on in Xul/Cocoonland. Awaiting for your comments!

Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)