cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [GSoC] status reports?
Date Wed, 24 Aug 2005 01:58:23 GMT
Hi Heh:

Joerg already answered the questions. Just some ideas between lines.....

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?
>(by the way, what's Apache's policy regarding including other
>free/open source code?)
>  
>
It depends. under wich license is released JSLib? I found the site, but 
I was not able to find the license:

http://jslib.mozdev.org/

BTW, MPL 1.1 is OK. MPL 1.0 is NOT OK.

>(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.
>  
>
Since there is no much time left and Joerg told AJAX is a quite complex 
issue. I will recomend to drop the AJAX support. (I hope Joerg agree 
with this decision too).

Please, check out the sources into :

https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul

>(3) Project release
>when the due day is up, what's the procedure to release the project? 
>
>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.
>  
>
You can stay in the community after GSoC. We welcome you!

>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.
>  
>
As Joerg, I don't see the need for a new block. There was an RT with the 
idea of support XForms [1] UI too. Don't worry, I am not going to 
include this in your project. ;-)

No matter if we will support XForms again (see mails since 2000 [2]) 
through cforms. The point is to enable Cforms to support different UIs.

[1] http://www.w3.org/MarkUp/Forms/
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&r=1&s=xform&q=b

Best Regards,

Antonio Gallardo


Mime
View raw message