cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@gmail.com>
Subject Re: XULifying CForms (yet another attempt?)
Date Tue, 11 Oct 2005 08:25:59 GMT
On 10/10/05, Stefano Mazzocchi <stefano@apache.org> wrote:
> 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".

>From what I reckon, the security sandbox shouldn't be that much of an
issue when dealing just with forms with no access to local resources.
Things of course would change when it comest to mangling with the
user's station, such as writing files or opening socket connections to
different hosts, but it shouldn't be different from applets, to say
the least.

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

Then again, a good lot of CForms is about reusable UI widgets, which
makes me think that we'll need XBL pretty soon. Is there a reason to
be scared though? I don't quite find XBL, in its simplest
incarnations, a daunting technology: if you use it as a poor's man
XSLT/macro processor it's more or less a piece of cake. I agree,
though, on staying away from overcomplication as much as we can.

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

<rant>
Now, call me an old fart, but I don't quite like the continuous and
oh-so-fashionable XML bashing I see nowadays. Clearly, writing angle
brackets all over the place isn't the most comfortable way of working,
but as long as I will be able to (per)use transformations so that I
will be able to generate an application using just an XSL stylesheet
from a model, I'll be an happy puppy. I just wish we had a
(successful) alternate syntax to avoid the carpal tunnel syndrome, yet
XSLT/XPath/validations and friends are just too powerful technologies
that make me easily fogive input verbosity.
</rant>

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

Yup, my point exactly. One of the first problems to dissect is how
CForms can go from a navigation based framework to a real GUI, where
navigation happens locally and it's calculated (mostly) on the client.
This is my first and foremost concern and at times I have the feeling
that Xul in CForms will have to remain a pure translation of html
interfaces (as in s/\.html/\.xul/g). Not a big deal after all.

> At the same time, browsers are *NOT* build with that in mind and "remote
> XUL" cannot prevent the users from clicking the back button

Well, this is where continuation should help us. At least possibly. :-)

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

Mime
View raw message