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 18:13:53 GMT
Christopher Oliver wrote:

> Sylvain Wallez wrote:
>> 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.
> There isn't (or shouldn't be) any limitation in functionality in the 
> V2 API. Do you see a  limitation?

I haven't made the exhaustive comparision between ScriptableWidget and 
every Widget implementation, but my bell rang when seeing all methods of 
all widgets gathered in a single class.

>> 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).
> It wasn't my goal to allow user-defined widgets, but if that is 
> desired it should be possible to refactor ScriptableWidget to make it 
> easy to do that.

AFAIU, this could be achieved by extending NativeJavaObject and just 
adding shortcut access to child widgets in has() and get(). Am I right?


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

View raw message