Gianugo Rabellino wrote:
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=25295 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!
I've been working heavily with XUL recently and I have to say, it could
be a refreshing experience if you were used to build DHTML applications.
At the same time, be aware that XUL is normally used "inside" the
mozilla security sandbox (say, loaded with chrome:// instead of being
loaded with http:// or file://), things change rather dramatically when
you use "remote XUL" (as it is called when you load XUL from http:// as
opposed to "local XUL".
Not many people publish their content directly in XUL.... not even the
most advanced web mails publish their content in XUL. In theory, there
is no reason why a web mail should not look and feel *EXACTLY* like
thunderbird... but it never happened and I suspect not for lack of
trying but for bugs or architectural limitations.
So, be aware that weird behavior might be due to that. (a way to know
for sure is to load your xul directly from chrome:// or by passing it as
a parameter to the moz command line)
As far as XBL goes, I would suggest to start without and see how far you
can keep going without it (which, for me, is pretty far since I'm not
developing reusable UI widgets)
As for as XHTML, XUL does *NOT* replace XHTML, in fact, you can consider
it as an extension to it. There are things that are, IMO, but better
than in XHTML (the vbox/hbox/flex model, for example, *WAAAAAY* better
than the stinking table/tr/td or even better than the CSS3 column
layouts) but some XUL widgets are nothing but reusable XHTML constructs
with embedded style and behavior (and that's why XBL is related to CSS,
you can think if XBL as an extension to CSS to make behavior portable
and isolated.. too bad they got the syntax wrong, the use of the XML for
XBL is a total golden hammer instance if you ask me)
As far as roundtripping, Ajax all over the place is the only reasonable
answer, IMO... be aware that this makes browser history and bookmarking
an interesting problem.
XUL is not going to change the way you interact with the server.... if
not to make it more obvious that there is no need to refresh a page if
the content changing is just marginal and there is no need to bookmark.
At the same time, browsers are *NOT* build with that in mind and "remote
XUL" cannot prevent the users from clicking the back button (and I'm not
sure if moz itself keeps the state in the remote xul fields... but I see
no reason why it shouldn't, being form fields in XUL the same XHTML dom
elements, just wrapped with more style and behavior)
Anyway, using XHTML/XUL multichanneling for CForms would indeed be nice.
--
Stefano.
