From MemberWiki

Attendees

• Bertrand,microsoft
• Lori,aptana
• Kevin,aptana
• Jon,IBM
• Kin,adobe
• Rich, IBM
• Stew, IBM
• Ted, OpenLink

Minutes

Reviewing Emailed Items:

Jon: Does require require a source attribute in the spec?

Jon: I propose its optional and defaults to the directory of the metadata file

Jon: Any comments?...none

Jon: Any objections?...none

Jon: Agreed

Jon: Next I'd like to discuss restoring the onChange pattern

Bertrand (in email) suggested we have a single property change callback with the property name and value, given that we cannot account for all the different possible naming patterns of onChange events.

Jon: The gadgets TF spoke of the same or similar mechanism, the signature though is propertyName, newValue, oldValue

Jon: Any objections to that signature?...none

Jon: OK, aggreed NOT to reinstante the onChange pattern and to support a single callback on the gadget wrapper called propertyChange(propertyName, newValue, oldValue)

Jon: Lets move on to the IDE workflows....

NOTE: Background email from Jon to frame the discussion:

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().

Jon: The Dreamweaver team want to simply take the content of a widget and generate a page containing the widget, they do not want to generate the widget wrapper.

Jon: Should we make the widget wrapper optional? and have the widget writer check for the existence of the object/API?

Kin: Lets back up, our goal is to tap into the worlds of 1000s of widgets out there, we haven't been focused on interopability of the runtimes.

Jon: There is overlap in the two approaches (IDE & Mashups) via the property node, for example setting the date property to publish to true or listen to true wires with the widgets together.

Kin: I see them as two different worlds, one close to the metal and the other concerned about interopability which are two different capabilities.

Jon: I believe the library providers (e.g. Dojo, Yahoo) will provide the wrapper.

Lori: Anybody should be able to describe their widgets.

Jon: The things that make a widget mashable are the listen and publish attributes

Kevin: So for simple widgets, we just don't have topics or listen/publish then

Kevin: I see the pub/sub/topic capabilities as optional

Lori: OK, given that, if you place a mashable widget on the page that expects those capabilities what happens?

Jon: Well for example if a widget requires getProperty

NOTE: More to come EDITOR:NOTE <work in progress, more to follow>