Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of joerg.heinicke@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <430BB042.1090700@gmx.de>
Date: Wed, 24 Aug 2005 01:24:50 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [GSoC] status reports?
References: <c3d00ed06addb5ebdcceb458b044ccaf@apache.org>
 <dbce5a7e050823153977f033ed@mail.gmail.com>
In-Reply-To: <dbce5a7e050823153977f033ed@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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