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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
