You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Timothy Larson <ti...@yahoo.com> on 2003/08/19 16:20:41 UTC
Status of Woody?
What is the current status of Woody?
I am running the nightly snapshot from 19-Aug-2003 03:17.
http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
Several of the samples do not work:
"Various" -- adds blank rows to "Firstname Lastname..." table at the bottom.
"XML Binding" -- Cannot add or remove contacts
"Bean Binding" -- Cannot add or remove contacts
I know development is ongoing. Are these samples just not updated yet to
match the code changes, or am I encountering Woody errors?
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Status of Woody?
Posted by Marc Portier <mp...@outerthought.org>.
Timothy,
just in case you were wondering...
the Thread (and approach towards solution) moved over here:
http://marc.theaimsgroup.com/?t=106137627800003&r=1&w=2
regards,
-marc=
Marc Portier wrote:
>
>
> Timothy Larson wrote:
>
>> What is the current status of Woody?
>
>
> status is still alfa (as in 'getting there')
>
> it should be usable for smaller short-lived projects here and now (gets
> the job done)
>
> but that usage is bound to generate more clues on typical usage that
> could guide us through essesntial refactorings
>
> in short: the code is probably more stable then the interfaces to it :-)
>
>> I am running the nightly snapshot from 19-Aug-2003 03:17.
>> http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
>>
>> Several of the samples do not work:
>> "Various" -- adds blank rows to "Firstname Lastname..." table at the
>> bottom.
>
>
> I'm running cvs head and didn't see this (the firstname should be filled
> in)
>
>> "XML Binding" -- Cannot add or remove contacts
>
> just tested this and saw the same, looks like a problem with the
> formhandler, I'll need a deeper look (but short on time here and now)
>
>> "Bean Binding" -- Cannot add or remove contacts
>
> didn't test, but is using the same formhandler, so kinda logic
>
>
> Uh, 2nd thought: not logic at all: the Various sample is using the same
> FormHandler and it works over there!
>
> So this is actually tied to how the flow is dealing with the
> formhandler! (that's a part I haven't looked into)
>
>> I know development is ongoing. Are these samples just not updated yet to
>> match the code changes, or am I encountering Woody errors?
>>
>
> probably a small Woody error in how it is tied up to the FlowScript...
> (need to check for updates in cvs there)
>
> regards,
> -marc=
> PS: Bruno is on holiday this week...
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Need help fixing a Woody flow sample
Posted by Timothy Larson <ti...@yahoo.com>.
For what its worth, I like both of the suggestions below:
--- Sylvain Wallez <sy...@anyware-tech.com> wrote:
...
> This makes me think that Form.show() does call sendPageAndWait, but
> provides no way for the script to pass its own biz-data to the view.
> This is IMO very limiting, as we may want the page template to display
> non-form data (actually, I will have this case very soon).
>
> So what about copying the prototype of sendPage[AndWait]() for show() ?
> This would then be Form.show("view.html", biz-data).
>
> Going back to the eventHandler/validator discussion, this also means
> that these should not more be passed as parameters (would be too long
> and thus inconvenient), but as properties of the Form. Same applies to
> locale. We'll then have :
>
> var form = new Form("form-decl.xml");
> form.eventHandler = function(event) {....}; // optional
> form.validator = function(form) {....}; // optional
> form.locale = myLocale; // optional
> form.show(
> "form-view.html",
> { user: userName, foo: bar} // optional
> );
>
This make more sense to me and looks like it will play well with
future changes to echo the validation logic in client-side javascript.
> In that case what about providing an optional feature in woody.js
> through a "requestAttribute" property ? If this property is defined,
> Form.show() stores the form in the corresponding request attribute, thus
> allowing the use of non flow-aware pipelines/components.
Very good.
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Need help fixing a Woody flow sample
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Marc Portier wrote:
>
>
> Timothy Larson wrote:
>
>> In woody.js [1] there was a change in version 1.6 that stopped calling:
>> cocoon.request.setAttribute(this.attrName, this.form);
>> and did this instead:
>> var bizData = { "woody-form": this.form };
>
>
> indeed, this lines up more with how flow is expected to be working
This makes me think that Form.show() does call sendPageAndWait, but
provides no way for the script to pass its own biz-data to the view.
This is IMO very limiting, as we may want the page template to display
non-form data (actually, I will have this case very soon).
So what about copying the prototype of sendPage[AndWait]() for show() ?
This would then be Form.show("view.html", biz-data).
Going back to the eventHandler/validator discussion, this also means
that these should not more be passed as parameters (would be too long
and thus inconvenient), but as properties of the Form. Same applies to
locale. We'll then have :
var form = new Form("form-decl.xml");
form.eventHandler = function(event) {....}; // optional
form.validator = function(form) {....}; // optional
form.locale = myLocale; // optional
form.show(
"form-view.html",
{ user: userName, foo: bar} // optional
);
>> This will require a change in this part of form1_success.xsp [2]:
>> // get reference to form and some of the widgets on it
>> Form form = (Form)request.getAttribute("form1");
>
>
> of course we need to consider that this xsp is also used in the
> context of the non-flowscript (but Actions) pipelines that ARE putting
> it just there.
In that case what about providing an optional feature in woody.js
through a "requestAttribute" property ? If this property is defined,
Form.show() stores the form in the corresponding request attribute, thus
allowing the use of non flow-aware pipelines/components.
> from that viewpoint I think it makes sense to let the flow-script bend
> a bit towards this forehoped reuse.
>
> in any case checking up on the woody_flow_example.js I see that it is
> not even adding any bizData in the sendPage call!
> (so there really is no way at all for the xsp to look for the form in
> any part of the context in this way)
>
> so shortest hack to me looks like adding
> cocoon.request.setAttribute("form1", form);
> in front of:
> cocoon.sendPage("form1-success-pipeline");
>
> in terms of best practice I would probably be advocating the use of
> jxtemplate in combinaion with flow rather then xsp
>
> (which would avoid your question about jpath logicsheet as well)
>
>> Field field = (Field)form.getWidget("email");
>> IIUC the change would involve using the jpath logicsheet, but I have
>> not been able to figure out how to get the Form object.
>> Anybody know how to do this?
>>
>> [1]
>> cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
>>
>> [2] cocoon-2.1/src/blocks/woody/samples/forms/form1_success.xsp
>>
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Need help fixing a Woody flow sample
Posted by Steven Noels <st...@outerthought.org>.
Marc Portier wrote:
> in terms of best practice I would probably be advocating the use of
> jxtemplate in combinaion with flow rather then xsp
+1
JXTemplate is massive but works nice and dandy.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Need help fixing a Woody flow sample
Posted by Timothy Larson <ti...@yahoo.com>.
Thanks for the help.
So far, this is the only way I have gotten this to work.
In the flow change:
cocoon.sendPage("success-pipeline");
to:
cocoon.sendPage("success-pipeline", {"woody":form.getModel()});
and in a JXTemplate file use this syntax to get the value of the
"name" widget:
<h3>Name: ${woody.name}</h3>
--Tim Larson
--- Christopher Oliver <re...@verizon.net> wrote:
> IMO the change to use "woody-form" is very poor choice because its not a
> valid Jexl identifier. This means that if you want to access it in
> JXTemplate you have to use this syntax:
>
> ${flowContext['woody-form'].someWidget}
>
> If you change it to say 'woodyForm' you can access it directly:
>
> ${woodyForm.someWidget}
>
> As far as Xsp, you should be able to access it using jpath:
>
> <jpath:value-of select="woody-form/someWidget"/>
>
>
> My $0.02,
>
> Chris
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Need help fixing a Woody flow sample
Posted by Christopher Oliver <re...@verizon.net>.
IMO the change to use "woody-form" is very poor choice because its not a
valid Jexl identifier. This means that if you want to access it in
JXTemplate you have to use this syntax:
${flowContext['woody-form'].someWidget}
If you change it to say 'woodyForm' you can access it directly:
${woodyForm.someWidget}
As far as Xsp, you should be able to access it using jpath:
<jpath:value-of select="woody-form/someWidget"/>
My $0.02,
Chris
Timothy Larson wrote:
>Comments inline...
>
>--- Marc Portier <mp...@outerthought.org> wrote:
>
>
>>Timothy Larson wrote:
>>
>>
>>>In woody.js [1] there was a change in version 1.6 that stopped calling:
>>> cocoon.request.setAttribute(this.attrName, this.form);
>>>and did this instead:
>>> var bizData = { "woody-form": this.form };
>>>
>>>
>...
>
>
>>so shortest hack to me looks like adding
>> cocoon.request.setAttribute("form1", form);
>>in front of:
>> cocoon.sendPage("form1-success-pipeline");
>>
>>
>
>I tried form, this.form, and form.form, but only form.form
>worked without changing the XSP:
> cocoon.request.setAttribute("form1", form.form);
>If you use this in the flowscript:
> cocoon.request.setAttribute("form1", form);
>then in XSP how do you get from request.getAttribute("form1")
>to a Form object? I am not too sure how this java<->javascript
>interfacing works yet.
>
>
>
>>in terms of best practice I would probably be advocating the use
>>of jxtemplate in combinaion with flow rather then xsp
>>
>>(which would avoid your question about jpath logicsheet as well)
>>
>>
>
>I would still like to know the jpath answer, and also how to use
>plain java to access a form held by the flow. Do you know how/have
>time to explain it?
>
>--Tim Larson
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
>
>
>
Re: Need help fixing a Woody flow sample
Posted by Timothy Larson <ti...@yahoo.com>.
Comments inline...
--- Marc Portier <mp...@outerthought.org> wrote:
> Timothy Larson wrote:
> > In woody.js [1] there was a change in version 1.6 that stopped calling:
> > cocoon.request.setAttribute(this.attrName, this.form);
> > and did this instead:
> > var bizData = { "woody-form": this.form };
...
> so shortest hack to me looks like adding
> cocoon.request.setAttribute("form1", form);
> in front of:
> cocoon.sendPage("form1-success-pipeline");
I tried form, this.form, and form.form, but only form.form
worked without changing the XSP:
cocoon.request.setAttribute("form1", form.form);
If you use this in the flowscript:
cocoon.request.setAttribute("form1", form);
then in XSP how do you get from request.getAttribute("form1")
to a Form object? I am not too sure how this java<->javascript
interfacing works yet.
> in terms of best practice I would probably be advocating the use
> of jxtemplate in combinaion with flow rather then xsp
>
> (which would avoid your question about jpath logicsheet as well)
I would still like to know the jpath answer, and also how to use
plain java to access a form held by the flow. Do you know how/have
time to explain it?
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Need help fixing a Woody flow sample
Posted by Marc Portier <mp...@outerthought.org>.
Timothy Larson wrote:
> In woody.js [1] there was a change in version 1.6 that stopped calling:
> cocoon.request.setAttribute(this.attrName, this.form);
> and did this instead:
> var bizData = { "woody-form": this.form };
indeed, this lines up more with how flow is expected to be working
> This will require a change in this part of form1_success.xsp [2]:
> // get reference to form and some of the widgets on it
> Form form = (Form)request.getAttribute("form1");
of course we need to consider that this xsp is also used in the
context of the non-flowscript (but Actions) pipelines that ARE
putting it just there.
from that viewpoint I think it makes sense to let the flow-script
bend a bit towards this forehoped reuse.
in any case checking up on the woody_flow_example.js I see that
it is not even adding any bizData in the sendPage call!
(so there really is no way at all for the xsp to look for the
form in any part of the context in this way)
so shortest hack to me looks like adding
cocoon.request.setAttribute("form1", form);
in front of:
cocoon.sendPage("form1-success-pipeline");
in terms of best practice I would probably be advocating the use
of jxtemplate in combinaion with flow rather then xsp
(which would avoid your question about jpath logicsheet as well)
> Field field = (Field)form.getWidget("email");
> IIUC the change would involve using the jpath logicsheet, but I have
> not been able to figure out how to get the Form object.
> Anybody know how to do this?
>
> [1] cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
> [2] cocoon-2.1/src/blocks/woody/samples/forms/form1_success.xsp
>
> --Tim Larson
>
(will test and commit above thoughts later)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Need help fixing a Woody flow sample
Posted by Timothy Larson <ti...@yahoo.com>.
In woody.js [1] there was a change in version 1.6 that stopped calling:
cocoon.request.setAttribute(this.attrName, this.form);
and did this instead:
var bizData = { "woody-form": this.form };
This will require a change in this part of form1_success.xsp [2]:
// get reference to form and some of the widgets on it
Form form = (Form)request.getAttribute("form1");
Field field = (Field)form.getWidget("email");
IIUC the change would involve using the jpath logicsheet, but I have
not been able to figure out how to get the Form object.
Anybody know how to do this?
[1] cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascript/woody.js
[2] cocoon-2.1/src/blocks/woody/samples/forms/form1_success.xsp
--Tim Larson
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Re: Status of Woody?
Posted by Marc Portier <mp...@outerthought.org>.
Timothy Larson wrote:
> What is the current status of Woody?
status is still alfa (as in 'getting there')
it should be usable for smaller short-lived projects here and now
(gets the job done)
but that usage is bound to generate more clues on typical usage
that could guide us through essesntial refactorings
in short: the code is probably more stable then the interfaces to
it :-)
> I am running the nightly snapshot from 19-Aug-2003 03:17.
> http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
> Several of the samples do not work:
> "Various" -- adds blank rows to "Firstname Lastname..." table at the bottom.
I'm running cvs head and didn't see this (the firstname should be
filled in)
> "XML Binding" -- Cannot add or remove contacts
just tested this and saw the same, looks like a problem with the
formhandler, I'll need a deeper look (but short on time here and now)
> "Bean Binding" -- Cannot add or remove contacts
didn't test, but is using the same formhandler, so kinda logic
Uh, 2nd thought: not logic at all: the Various sample is using
the same FormHandler and it works over there!
So this is actually tied to how the flow is dealing with the
formhandler! (that's a part I haven't looked into)
> I know development is ongoing. Are these samples just not updated yet to
> match the code changes, or am I encountering Woody errors?
>
probably a small Woody error in how it is tied up to the
FlowScript... (need to check for updates in cvs there)
regards,
-marc=
PS: Bruno is on holiday this week...
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Status of Woody?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Timothy Larson wrote:
>What is the current status of Woody?
>I am running the nightly snapshot from 19-Aug-2003 03:17.
>http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
>Several of the samples do not work:
> "Various" -- adds blank rows to "Firstname Lastname..." table at the bottom.
> "XML Binding" -- Cannot add or remove contacts
> "Bean Binding" -- Cannot add or remove contacts
>I know development is ongoing. Are these samples just not updated yet to
>match the code changes, or am I encountering Woody errors?
>
There has be no code change that should have "intentionally" broken
these samples.
This means we have to investigate and fix the bug ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com