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