On 10/10/05, Joerg Heinicke <[EMAIL PROTECTED]> wrote: > Gianugo Rabellino <gianugo <at> gmail.com> writes: > > > 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). > > Is it an either-or-decision?
Well, the way I see it is that either the Xul incarnation of CForms provides a different roundtrip model for client-server communication or it would "just" be a 1:1 mapping to the current HTML forms. Not much added value compared to an HTML rendering, given it would still be browser based *and* strongly tied to just one browser. Why should anyone choose to use the Xul version nowadays then? > > 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. > > Claas and I came to the conclusion that Ajax as-is does not work with XUL. If you mean as-is as the current Cocoon incarnation, I don't quite see why, apart from some tweaks that might be necessary. The whole idea of Ajax actually was in Xul since day one, given that manipulation of the widget tree is delegated to javascript and network communication has to happen through XmlHttpRequest. And I have the perception that XBL might play a role even here > > > 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. > > That's really advanced stuff. Starting with simple stuff will be hard enough > ;) Hmm... point is I'm afraid you won't go much farther than a few text input, checkboxes, radios and selection lists without XBL... > Breaking the ice might be necessary :) Wait for the code submit and the > status I > will send. Sure thing, looking forward to it! -- 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/)
