Tim Larson wrote:
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.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
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
