I did some thinking about how the widget APIs fit into design-time
workflows such as we have with traditional IDEs. Here are all of the APIs
we have so far and my guess about their relevance and impact to IDEs:
* getHubConnection(): Needed. Without this, a widget can't use the OpenAjax
Hub.
* registerCallback(): Needed. Here are the list of events that can have
callbacks registered:
--- load: Needed
--- unload: Needee
--- remove: Usually not used in IDE workflows
--- insert:: Needed
--- viewChange: Usually not used in IDE workflows
--- resize: Usually not needed
* unregisterCallback(): Usually not used in IDE workflows
* getAvailableDimensions(), getDimensions(), adjustDimensions(): Usually
not needed in IDE workflows
* getPropertyValue(): Needed
* setPropertyValue(): Usually not used in IDE workflows
* getSupportedViews(): Usually not used in IDE workflows
* requestNavigateTo(): Usually not used in IDE workflows
My conclusions:
(1) In order to support the above, IDEs need to set up the widget with
wrapper JavaScript such that: for any <javascript> element the "this" set
to an object which supports some of the above widget APIs, such as
this.getPropertyValue() will work
(2) We have to be clear to widget authors that the widget APIs are all
optional. Therefore, the widget needs to check to see if an API is present
before invoking it. For example, it's OK for an IDE to not support
getAvailableDimensions(), getDimensions(), adjustDimensions().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080826/60111155/attachment.html