Gianugo Rabellino wrote:
On 10/10/05, Stefano Mazzocchi <[EMAIL PROTECTED]> 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.

That is the theory. In practice, I heard it's a lot more painful, due to bugs and overconcerned security restrictions.

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.

Oh, no, nothing to be really scared off. Just a way to reduce the barrier of entry... but if you think you need it, go for it.

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>

all right, all right. look, it can be worse, I work with people that want everything to be RDF ;-)

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.

Would be nice to work with other types of interaction too, though, like wizards and decks, but that's another story.

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



--
Stefano.

Reply via email to