cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: XULifying CForms (yet another attempt?)
Date Mon, 10 Oct 2005 17:30:47 GMT
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.


Mime
View raw message