cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@gmail.com>
Subject Re: XULifying CForms (yet another attempt?)
Date Tue, 11 Oct 2005 12:34:02 GMT
On 10/11/05, Joerg Heinicke <joerg.heinicke@gmx.de> 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?
>
> 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.

I see your point. Problem is whether the CForms approach can be
abstracted so that a CForm can be transparently rendered both as HTML
or as XUL, something I don't see likely to happen at the moment.
Consider repeaters in a non-Ajax scenario (i.e. no ajax=true): the
HTML CForm will need a roundtrip to the server, which would be
overkill for the more powerful XUL rendering.

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

Well, definitely the ideal scenario would be the (rich) client
handling navigation and posting pure data back and forth (either bound
or unbound to the underlying model - better, the underlying model's
XML view, even for objects). Then again, however, this would stretch
the CForm paradigm quite a bit. Not sure it's feasible without a major
impact in CForms as a whole.

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

Well, I have been tempted by XUL templates, then took some time to
read a few rants here and there and became convinced that it's not
that mature and reliable as a technology (see
http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html).
I know I keep pestering with XBL, but I have the gut feeling that XBL
won't be as difficult as Xul templates and could provide a much better
experience for form template writers. But I really need to get my feet
wet and provide some code.

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

Uhm, so what? Aren't we targetting XUL in Gecko?

>  It's similar to XUL template in that extent that it tries to
> match on elements and creates some markup if an XPath matches.

Yup, document.evaluate() is pretty nice and you can do quite a few
things with it.

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

Again, why are you worried about cross-browser compliance?

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

Well, if the alternative is XUL templates, I'm not sure I want to
prove you right. ;-)

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

Easy? Yes. Clean? Not so sure... voices in my head keep whispering
"use  XML flying back and forth instead than plain & constructed
request parameters". Having CForms capable to deal with forms posted
as XML would have the great bonus of being able to interact with
XForms on the client side, which, hey, would not be that bad! :-)

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

Mime
View raw message