cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: XULifying CForms (yet another attempt?)
Date Tue, 11 Oct 2005 10:23:13 GMT
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


Mime
View raw message