From MemberWiki

Contents 1 Goals 2 Scenario 1 2.1 Description 2.2 Diagram 2.3 Discussion/Questions 3 Scenario 2 3.1 Description 3.2 Diagram 3.3 Discussion/Questions 4 Scenario 3 4.1 Description 4.2 Diagram 4.3 Discussion/Questions 5 Other Scenarios for Consideration

Goals

• Keep it simple, the programming model for the gadget writer is as straightforward as possible while enabling advanced capabilities.
• The Gadget-to-Hub protocol is the same in the various hosting scenarios below.
• Composting of IDE Widgets are post release 1.0 of the specification, however, care should be taken to ensure the programming model provides the appropriate recursive structures (e.g. composites-of-composites-of-composites).

Scenario 1

Description

In the scenario all gadgets are run inline or type='html' and there is a single hub instance that the gadgets will publish and subscribe to. For property wiring the container will handle the underlying registration and event listening to and from the hub. For example:

<widget name="Calendar" xmlns="http://openajax.org/widget" specVersion="0.1b" scope="Calendar" >
     ...
    <properties>
      <property name='date' type='string' publish='true' topic='date'/>
    </properties>
   ...
</widget>

The calendar gadget above publishes on the topic date.

<widget name="Echo" xmlns="http://openajax.org/widget" specVersion="0.1b" >
     ...
    <properties>
      <property name='text'' type='string' listen='true' topic='date'/>
    </properties>
   ...
</widget>

The Echo gadget above listens on the topic date.

The runtime is responsible for 'wiring' the publishing and listening behaviors defined by the gadgets.

NOTE: In this scenario the native ajax toolkit may have its own publish and subscribe mechanism.

Diagram

Discussion/Questions

Scenario 2

Description

This scenario builds on the first Scenario by adding a 'private hub' instance. Gadget X in this scenario is implemented using components from the Ajax native toolkit that are NOT OAA gadgets, however, the implementation uses a private hub for communication between the native components (GadgetY & GadgetZ in the Diagram below). The aggregate (GadgetX) is still responsible for the external contract for the OAA Gadget, that is, emitting and consuming data from the logical "global" Hub.

Diagram

Discussion/Questions

• In this scenario is Gadget X (the aggregate) responsible for creating the 'private' Hub?
• Gadget Y & Z must somehow obtain and handle to the Hub, if they use the Hub 1.0 method (i.e. OpenAjax.hub.publish) how will the container provide a unique handle?

Scenario 3

Description

Scenario 3 builds on the previous two scenarios by introducing the notion of sandbox or untrusted site for the gadget to be hosted within. In this model the gadget site provides a logical global hub which hosts the previous two styles of interactions. As stated above, the goal is to have the gadget run untouched in this mode as well. It is the responsibility of the containing page or composite to provide the correct runtime for events to flow from the sandbox to the containing logical hub instance.

Diagram

Discussion/Questions

A mashup canvas will need to dynamically load widgets given a reference to the gadget, for example, a URL to the specification document. A gadget will need to be dynamically integrated into an existing pages as per the policy of the mashup canvas or the content type suggestion of the gadget.

• html or inline gadget - in this case the assets of the gadget (e.g. JavaScript & CSS file) will need to by dynamically spliced into the document and interpreted.
• frame - the gadget is loaded into a sandbox area using the methods dictated by the Hub 1.1.

• What are the requirements for the 'IFRAMED' environment?
  • Script includes, bootstrap code, registration?
  • Whose responsibility is it to bootstrap the environment hub? container? both??
• How are parameters passed to the widget? on the URL?
• How are parameters saved? (if appropriate)
• When editing properties of a given gadget (using a system generated property editor) the assembly canvas is responsible for (re)wiring the gadget and updating property values, at what point should the gadget be informed of the new property values?
• How are non-constructor based properties updated on the gadget instance? For example, are there setters & getters?
  • NOTE: It is desirable not to recreate the gadget is possible

Other Scenarios for Consideration

• Nested Inline
•  ??