cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: v2 forms flowscript example
Date Fri, 19 Mar 2004 17:34:55 GMT
Christopher Oliver wrote:

> Tim Larson wrote:
>> In: cocoon-2.1/src/blocks/forms/samples/v2/forms_flow_example.js
>> Should this:
>>    // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>    //
>>    // Its subwidgets can be accessed by id.
>> be changed to this:
>>    // 'wid' is a javascript wrapper of the Cocoon Form widget.
>>    //
>>    // The javascript wrappers of its subwidgets can be accessed by id.
>> to be accurate?
>> --Tim Larson
> Actually, I don't think it should even mention "wrappers". IMO, the 
> underlying Java widgets are an implementation detail of the Flowscript 
> API and should never be used directly in a script. The documentation 
> should simply say that the return value of Form.getWidget() is the JS 
> representation of <fd:form> instance.

Why is there a need to have a different API for widgets when used from 
JS than when used from Java? IMO, this is arbitrarily limiting the 
features available in flowscript.

The good thing of these wrappers is that they simplify the notation for 
browsing the widget tree (by avoiding 'getWidget()'), but the fact that 
some limits come with this simplified notation is IMO not good.

Furthermore, what if someone designs their own new widget with some 
specific APIs? They simply cannot access them unless they modify the 
ScriptableWidget class, which will hold all APIs of all widgets (this is 
already the case with e.g. repeater-specific functions).

Isn't there a way with Rhino to simply augment a wrapped Java object 
with new properties (here the children widgets) without having to fully 
reimplement all of its methods?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message