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?
I think it's clear using XUL the HTML-way makes no sense. My either-or was related to the two mentioned alternatives. And these two depend heavily on the widget IMO. > > > 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 I meant the browser update instructions which is actually only a client-side replacement of elements. The idea of rich clients includes the move of the view to the client, which does not happen with the current Ajax stuff. Only data should be sent to the client. This is what the RDF and XUL template stuff is about. My first idea was to provide one CForms template which knows how to display all the widgets described in the RDF, which means the RDF has to include information about the view (e.g. radio buttons vs. drop-down list). Besides this disadvantage Claas mentioned it is impossible to match all and everything in my super CForms template. So we switched to the approach I attached to the bug. Clean separation of data and view (form instance markup is generated with the FormsGenerator, so it contains no details about the view). The template is only on the client, but form-specific. That's what form1_template.xul is for example. Unfortunately this approach seems to be horrible to template writers. If you have to learn the concepts of RDF and this horrible templates of XUL before getting something to work ... Our conclusion: it's neither the correct approach. Now Claas tries something else on the client-side which is more or less a replacement for XUL templates: DOM 3 XPath or XSLT. The XPath approach would only work for Gecko engine at the moment, but maybe also in future IEs. It's similar to XUL template in that extent that it tries to match on elements and creates some markup if an XPath matches. XSLT should work even now in nearly all browsers. This is more or less the move of the stylesheets currently on the server to the client. > Hmm... point is I'm afraid you won't go much farther than a few text > input, checkboxes, radios and selection lists without XBL... You can get really far without XBL. By the way, the other part of a client-server-roundtrip, sending a request, is quite easy. Just walking through the DOM, collecting all form elements and constructing a request is easy. Jörg
