Hello Heh,
On 24.08.2005 00:39, Heh wrote:
Since last discussion, I've been working on how to use rdf data source
and xul template to
populate XUL widgets, how to connect to cocoon using XMLHttpRequest
and update widgets through js scripts. So far I am able to create
simple examples to demonstrate those techniques (will be detailed in
documents).
Issues:
(1) XUL template
XUL template is hard to work with, it's a black box, no error
reporting, all silient failures. You never know if the failures come
from incorrectly formatted rdf file, or rdf file not loaded at all, or
the template predicates unmatched, or the illegal template actions? I
googled around, there seems no useful supporting tools for XUL
tempate, and for a few times this top-ranked rants about xul template
showed up:
http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html
it recommeded to use mozilla JSLib to control the behavior of XUl
widgets, I was thinking about that, what do u think?
in open source you are almost never the only or the first one fighting
with a problem. For the XUL templates you could have asked either in the
Mozilla community or here. We have started a XUL project 3 years ago and
I have also fought *very* much with XUL templates. I don't know about
JSLib, but I used the DOM inspector heavily that is delivered with
Mozilla (don't know about Firefox). With it you can see at least what
the source of failure is, though not why. Yeah, working with XUL
templates was always like walking in a dark foggy night through an
unknow country :) But the application is still running, in production
use (though not publicly) and maintained.
(by the way, what's Apache's policy regarding including other
free/open source code?)
This heavily depends on the other software's license. It must be
compatible to the Apache License.
(2) CForms Browser Update mechanism
how to extend this beautiful BU mechanism to handle XUL widgets?
Currently the examples I've been working on are all standalone, which
means that the xul file is delivered on cocoon as it is by
<map:read/>, not through pipeline, pieces of js scripts have been
written to handle the widget behaviors. While the BU mechanism is tied
to the cforms widgets (correct me if i am wrong), to utilize the BU
or the ajax support, the xul widgets has to be transformed to the
cform widgets to be recognized by the system, i tried to modify these
files:
forms-page-styling.xsl
forms-advanced-field-styling.xsl
forms-field-styling.xsl
forms-samples-styling.xsl
simple-page2html.xsl
but no luck, I don't know to handle those fields with atributes like
"onchange", also the set of xul widgets are asymmetric to the cform
ones.
The question is not very specific, but most of the information of the
form instance must go to the client (in rdf format). The above
stylesheets should be that much involved, the structure of them is
probably not appropriate. Probably only one stylesheet transforming form
instance XML representation to RDF would be sufficient. For a real
AJAX-like handling it gets more complicated of course.
(3) Project release
when the due day is up, what's the procedure to release the project?
You have a svn account to commit your stuff.
Future:
this GSoC project is just a beginning, that's for fure. During these
days, I learned a lot, also found out there are lots of things worthy
> to do, the momentum has been built, I don't want to lose it.
This project is about XUL and CForms, going forward I think it's more
nature to continue to work on the cocoon XUL support as a separate new
block, the reason is, just briefly put here, the CForms is designed to
hand UI on the backend, while XUL is on the frond end,
to mix them up is like to put one interface on another, it's just too much.
This is just my own opion based on what I've learned from working on
this project. Open for discussion of course.
I don't see we need another block, but that might evolve. For the moment
I think it's appropriate to put it besides the HTML stuff, starting (as
HTML) in the samples section maybe.
Joerg
