cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: v2 forms flowscript example
Date Fri, 19 Mar 2004 19:45:16 GMT
Sylvain Wallez wrote:

> 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.
>
 From my experience this is a common design pattern for wrapping 
existing API's. Other approaches are of course possible.

>>> 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?
>
If adding "shortcut access" was all that was required, perhaps. However, 
extending Rhino internal classes (like NativeJavaObject) is not a good 
idea in my opinion. Moreover, ScriptableWidget provides additional 
functionality beyond that, namely the ability to set JS functions as 
event handlers, coerecions of JS Number to CForms numeric datatypes, 
initialization of complex widgets using JS objects, and notification of 
validation errors.

Regards,

Chris


Mime
View raw message