Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <434BBCA7.3090002@apache.org>
Date: Tue, 11 Oct 2005 09:22:47 -0400
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: XULifying CForms (yet another attempt?)
References: <7557e99f0510100801n3835a46nd8496df9c0b8bbb9@mail.gmail.com>
	 <434AA547.7070009@apache.org>
 <7557e99f0510110125u61c890b0xb4fb676b35b2d92e@mail.gmail.com>
In-Reply-To: <7557e99f0510110125u61c890b0xb4fb676b35b2d92e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gianugo Rabellino wrote:
> 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.

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.