cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Need help fixing a Woody flow sample
Date Thu, 21 Aug 2003 14:14:24 GMT
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 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"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
  { 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, 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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message