You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2005/07/25 19:58:58 UTC
GSoC project - cform XUL status request
Hi Heh:
Can you send a status report about how the work is going in you GSoc
project?
Best Regards,
Antonio Gallardo.
Re: GSoC project - cform XUL status request
Posted by Heh <vi...@gmail.com>.
On 7/26/05, Antonio Gallardo <ag...@agssa.net> wrote:
> Good. Please also review the AJAX suport for CForms that Sylvain wrote 3
> months ago:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111348478712544
>
After reading the above post and this thread of discussions, I
realized that I went to the wrong direction, I need to re-think the
whole thing.
My initial thought is sort of like what Sylvain mentioned in the
beginning of his email, I tended to divide the problem from outside
in, yet complicate the problem. A better way, as shown in that post,
is to analyze the problem in an inside-out way, so more elegant and
general solutions could be reached.
This post is indeed very helpful, I appreciate all the info you guys provided.
-Heh
Re: GSoC project - cform XUL status request
Posted by Antonio Gallardo <ag...@agssa.net>.
Heh wrote:
>Hi Antonio,
>
>
Hi! :-)
Sorry for my late answer. I have been very busy today.
>a basic set of XUL form widgets are able to be rendered through the
>publishing pipeline, by add new XSLT transformers based on forms field
>stying and forms page stying. A few bugs need to be fixed, also not
>all form attributes are considered, some other issues like XUL form
>elements positioning need to match up with the original html form. So
>the XUL form display part is finishing up, at least the bone is there.
>
>
Excelent! In my next mail, I will start a vote aimed to give you
committer access to share your work with the comunity.
>Next is the XUL form processing. My understanding is that XUL is
>inherently a "form", that's what a User Interface is supposed to do.
>But a html form is an add-on to the HTML document, so compared to
>HTML forms, XUL has no equivalent to the <FORM> tag (maybe because
>it's already a form), and if a XUL application is to behave like an
>HTML form, then form submission scripts need to be added to each XUL
>form. I am thinking about how to use XMLHttpRequest object to
>implement XUL form submission functionality. Any suggestions are
>welcome here, it's the design issue, what aspects should I consider?
>
>
Good. Please also review the AJAX suport for CForms that Sylvain wrote 3
months ago:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111348478712544
>I try to put up a minimum set of working functions as soon as
>possible, get some feedback, and gradually add more or refine. By
>participating this project, I am also interested in knowing how FOSS
>works from the point of view of Software Engineering, what's the
>differences between FOSS development and proprietary software
>development in terms of software engineering? one thing I learned so
>far is that everything seems to be open here, open design, open
>communication, open vote, etc.
>
>This is a big topic, so I'll start with the testing part, does there
>really exist alpha and beta test in FOSS development? How cocooners
>conduct unit testing, regression testing( or say best practices, what
>kind of testing tools are you using)? If I have some code ready, what
>should I do next to efficiently and effectively get any feedback from
>the community?
>
>
Perhaps this is not exactly written as you might expect, but I think you
should read this to understand more about the FOSS development methodology:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
>Thanks in advance.
>
>
Thanks to you! ;-)
Best Regards,
Antonio Gallardo
Re: GSoC project - cform XUL status request
Posted by Upayavira <uv...@odoko.co.uk>.
Joerg Heinicke wrote:
> On 27.07.2005 00:34, Upayavira wrote:
>
>>> In your previous email, you mentioned something like:
>>> "The really interesting part with XUL is to use it as rich client,
>>> i.e. to
>>> avoid rendering the complete page on each request, but only the parts
>>> that
>>> need to be rendered."
>>>
>>> Are you talking about some sort of "one-screen form handling" feature
>>> like this:
>>>
>>> https://reservations.ihotelier.com/onescreen.cfm?hotelid=2054&languageid=1
>>>
>>>
>>> the above is implemented in flash though, I think we can achieve
>>> similar effects in XUL.
>>> I like this feature, it could be used in other situations like
>>> checkout. Should I include this feature into my project? Antonio? I am
>>> not sure how much work is needed to implement this feature.
>>
>>
>>
>> If you do, you might want to look at Sylvain's work on Ajax with
>> CForms. With that, JavaScript on the browser does XMLHTTPRequests back
>> to Cocoon, and CForms replies with partial XML based upon just the
>> part of the form that has changed. This, to my ill-informed eye seems
>> like much the same functionality as you would need for XUL.
>
>
> With the difference that you don't need AJAX with XUL. Or better said -
> as both rely on XMLHttpRequest, so that's not exactly the difference -
> you don't pass complete parts of a page as HTML snippets to the client,
> which will replace existing parts in a page with the new stuff using DOM
> functions. You simply reload a RDF datasource and the template on the
> client will rebuild the specific parts depending on this datasource.
> IIRC I posted two links in one of these mails. If not I can search for
> them again (it was on http://www.xulplanet.com).
Exactly. What I should have said is that therefore the Cocoon side will
be much the same, even if the client side is very different.
Upayavira
Re: GSoC project - cform XUL status request
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.07.2005 07:04, Antonio Gallardo wrote:
>>> If you do, you might want to look at Sylvain's work on Ajax with
>>> CForms. With that, JavaScript on the browser does XMLHTTPRequests
>>> back to Cocoon, and CForms replies with partial XML based upon just
>>> the part of the form that has changed. This, to my ill-informed eye
>>> seems like much the same functionality as you would need for XUL.
>>
>> With the difference that you don't need AJAX with XUL. Or better said
>> - as both rely on XMLHttpRequest, so that's not exactly the difference
>> - you don't pass complete parts of a page as HTML snippets to the
>> client, which will replace existing parts in a page with the new stuff
>> using DOM functions. You simply reload a RDF datasource and the
>> template on the client will rebuild the specific parts depending on
>> this datasource. IIRC I posted two links in one of these mails. If not
>> I can search for them again (it was on http://www.xulplanet.com).
>
> Do you mean something like this demo:
>
> http://www.faser.net/mab/chrome/content/mab.xul
>
> More info here: http://www.faser.net/mab/
Yeah, this looks like a perfect example. It gives a real Rich Client
feeling.
Joerg
Re: GSoC project - cform XUL status request
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke wrote:
> On 27.07.2005 00:34, Upayavira wrote:
>
>>> In your previous email, you mentioned something like:
>>> "The really interesting part with XUL is to use it as rich client,
>>> i.e. to
>>> avoid rendering the complete page on each request, but only the
>>> parts that
>>> need to be rendered."
>>>
>>> Are you talking about some sort of "one-screen form handling"
>>> feature like this:
>>>
>>> https://reservations.ihotelier.com/onescreen.cfm?hotelid=2054&languageid=1
>>>
>>>
>>> the above is implemented in flash though, I think we can achieve
>>> similar effects in XUL.
>>> I like this feature, it could be used in other situations like
>>> checkout. Should I include this feature into my project? Antonio? I am
>>> not sure how much work is needed to implement this feature.
>>
>>
>>
>> If you do, you might want to look at Sylvain's work on Ajax with
>> CForms. With that, JavaScript on the browser does XMLHTTPRequests
>> back to Cocoon, and CForms replies with partial XML based upon just
>> the part of the form that has changed. This, to my ill-informed eye
>> seems like much the same functionality as you would need for XUL.
>
>
> With the difference that you don't need AJAX with XUL. Or better said
> - as both rely on XMLHttpRequest, so that's not exactly the difference
> - you don't pass complete parts of a page as HTML snippets to the
> client, which will replace existing parts in a page with the new stuff
> using DOM functions. You simply reload a RDF datasource and the
> template on the client will rebuild the specific parts depending on
> this datasource. IIRC I posted two links in one of these mails. If not
> I can search for them again (it was on http://www.xulplanet.com).
Do you mean something like this demo:
http://www.faser.net/mab/chrome/content/mab.xul
More info here: http://www.faser.net/mab/
Best Regards,
Antonio Gallardo
Re: GSoC project - cform XUL status request
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.07.2005 00:34, Upayavira wrote:
>> In your previous email, you mentioned something like:
>> "The really interesting part with XUL is to use it as rich client,
>> i.e. to
>> avoid rendering the complete page on each request, but only the parts
>> that
>> need to be rendered."
>>
>> Are you talking about some sort of "one-screen form handling" feature
>> like this:
>>
>> https://reservations.ihotelier.com/onescreen.cfm?hotelid=2054&languageid=1
>>
>>
>> the above is implemented in flash though, I think we can achieve
>> similar effects in XUL.
>> I like this feature, it could be used in other situations like
>> checkout. Should I include this feature into my project? Antonio? I am
>> not sure how much work is needed to implement this feature.
>
>
> If you do, you might want to look at Sylvain's work on Ajax with CForms.
> With that, JavaScript on the browser does XMLHTTPRequests back to
> Cocoon, and CForms replies with partial XML based upon just the part of
> the form that has changed. This, to my ill-informed eye seems like much
> the same functionality as you would need for XUL.
With the difference that you don't need AJAX with XUL. Or better said -
as both rely on XMLHttpRequest, so that's not exactly the difference -
you don't pass complete parts of a page as HTML snippets to the client,
which will replace existing parts in a page with the new stuff using DOM
functions. You simply reload a RDF datasource and the template on the
client will rebuild the specific parts depending on this datasource.
IIRC I posted two links in one of these mails. If not I can search for
them again (it was on http://www.xulplanet.com).
Joerg
Re: GSoC project - cform XUL status request
Posted by Upayavira <uv...@odoko.co.uk>.
Heh wrote:
> Joerg,
>
> In your previous email, you mentioned something like:
>
> "The really interesting part with XUL is to use it as rich client, i.e. to
> avoid rendering the complete page on each request, but only the parts that
> need to be rendered."
>
> Are you talking about some sort of "one-screen form handling" feature like this:
>
> https://reservations.ihotelier.com/onescreen.cfm?hotelid=2054&languageid=1
>
> the above is implemented in flash though, I think we can achieve
> similar effects in XUL.
> I like this feature, it could be used in other situations like
> checkout. Should I include this feature into my project? Antonio? I am
> not sure how much work is needed to implement this feature.
If you do, you might want to look at Sylvain's work on Ajax with CForms.
With that, JavaScript on the browser does XMLHTTPRequests back to
Cocoon, and CForms replies with partial XML based upon just the part of
the form that has changed. This, to my ill-informed eye seems like much
the same functionality as you would need for XUL.
Upayavira
Re: GSoC project - cform XUL status request
Posted by Heh <vi...@gmail.com>.
Joerg,
In your previous email, you mentioned something like:
"The really interesting part with XUL is to use it as rich client, i.e. to
avoid rendering the complete page on each request, but only the parts that
need to be rendered."
Are you talking about some sort of "one-screen form handling" feature like this:
https://reservations.ihotelier.com/onescreen.cfm?hotelid=2054&languageid=1
the above is implemented in flash though, I think we can achieve
similar effects in XUL.
I like this feature, it could be used in other situations like
checkout. Should I include this feature into my project? Antonio? I am
not sure how much work is needed to implement this feature.
-Heh
On 7/26/05, Joerg Heinicke <jo...@gmx.de> wrote:
> There is no form processing built into XUL. You have to implement it
> yourself using XMLHttpRequest. That was what my mails regards the
> proposal on the list was about. You can read it in the archives. Also
> there is not much sense about handling XUL exactly like HTML. XUL has
> its own templating mechanism.
>
> Joerg
>
Re: GSoC project - cform XUL status request
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.07.2005 20:06, Heh wrote:
> Next is the XUL form processing. My understanding is that XUL is
> inherently a "form", that's what a User Interface is supposed to do.
> But a html form is an add-on to the HTML document, so compared to
> HTML forms, XUL has no equivalent to the <FORM> tag (maybe because
> it's already a form), and if a XUL application is to behave like an
> HTML form, then form submission scripts need to be added to each XUL
> form. I am thinking about how to use XMLHttpRequest object to
> implement XUL form submission functionality. Any suggestions are
> welcome here, it's the design issue, what aspects should I consider?
There is no form processing built into XUL. You have to implement it
yourself using XMLHttpRequest. That was what my mails regards the
proposal on the list was about. You can read it in the archives. Also
there is not much sense about handling XUL exactly like HTML. XUL has
its own templating mechanism.
Joerg
Re: GSoC project - cform XUL status request
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 26 juil. 05, à 20:06, Heh a écrit :
> ...If I have some code ready, what
> should I do next to efficiently and effectively get any feedback from
> the community?...
The best thing (actually *the* thing to do) is to make this code
available to everybody by adding it to
http://svn.apache.org/repos/asf/cocoon/whiteboard/ (unless Antonio was
meaning to have it under another path). Commit early, commit often!
I don't think you have sufficient rights to do it yourself now, but if
you can prepare a patch (or at least a tarball if yours is only new
code), we'll take care of putting it into the repository. In this way,
others have a chance to play with it and comment.
-Bertrand
Re: GSoC project - cform XUL status request
Posted by Heh <vi...@gmail.com>.
Hi Antonio,
a basic set of XUL form widgets are able to be rendered through the
publishing pipeline, by add new XSLT transformers based on forms field
stying and forms page stying. A few bugs need to be fixed, also not
all form attributes are considered, some other issues like XUL form
elements positioning need to match up with the original html form. So
the XUL form display part is finishing up, at least the bone is there.
Next is the XUL form processing. My understanding is that XUL is
inherently a "form", that's what a User Interface is supposed to do.
But a html form is an add-on to the HTML document, so compared to
HTML forms, XUL has no equivalent to the <FORM> tag (maybe because
it's already a form), and if a XUL application is to behave like an
HTML form, then form submission scripts need to be added to each XUL
form. I am thinking about how to use XMLHttpRequest object to
implement XUL form submission functionality. Any suggestions are
welcome here, it's the design issue, what aspects should I consider?
I try to put up a minimum set of working functions as soon as
possible, get some feedback, and gradually add more or refine. By
participating this project, I am also interested in knowing how FOSS
works from the point of view of Software Engineering, what's the
differences between FOSS development and proprietary software
development in terms of software engineering? one thing I learned so
far is that everything seems to be open here, open design, open
communication, open vote, etc.
This is a big topic, so I'll start with the testing part, does there
really exist alpha and beta test in FOSS development? How cocooners
conduct unit testing, regression testing( or say best practices, what
kind of testing tools are you using)? If I have some code ready, what
should I do next to efficiently and effectively get any feedback from
the community?
Thanks in advance.
-Heh