Gadget Open Issues

From MemberWiki

Jump to: navigation, search

Contents

Gadget Containment

Gadgets can visually contain other gadgets, for example an accordion control may contain other gadgets. Developers and mashup assemblers will most likely blur the boundary between gadget toolkits and wish to embed child gadgets from one toolkit into container gadgets from another.

The specification should enable gadgets to declare if they are containers and where children can be placed during the design phase. The challenge of identifying "where" containment is possible differs from toolkit to toolkit, for example, declarative models are easier than imperative model.

SEN: This section and Drag & drop introduce a level of complexity, while important, we need to consider impact to the v1 spec

Drag & Drop

Several existing widget/gadget models define a drag & drop mechanism used to directly move content elements from one place to another.

The toolkits vary from declarative to imperative.

Challenges of cross-toolkit

  • Dragging between sandboxed containers is very difficult
  • Completely different runtime implementations

SEN: Given the deep rooted complexities of cross-toolkit drag & drop, I believe we should consider a toolkit neutral library which gadget writers can write to to enable drag & drop of their gadgets and its contents. This approach is similar to the Hub model, in fact, drag & drop can be thought of as copy-paste or cut-paste actions which MIGHT travel through a similar secure mechanism as the hub.

Gadget Lifecycle

Gadget Creation

The proposal currently identifies a set of properties whose values are passed to the 'constructor' of the gadget. We have the following questions:

  • Overloading the semantics of the properties/property elements for the use in constructors may lead to confusion.
  • Can we simply use the API metadata which already identifies constructors as a mechanism for constructing the gadget? (see OpenAjax Metadata Specification API Metadata)
       <constructors>
           <constructor scope="instance">
               <description>Constructor description</description>
               <parameters>
                   <parameter name="message" required="true" type="String">
                       <description>Parameter description</description>
                   </parameter>
               </parameters>
               <return-types> <!-- See IDE Issue 10 -->
                   <return-type type="libraryname.ClassName"/>  <!-- ??: Need to reconcile with our rules for datatypes -->
               </return-types>
           </constructor>
  • If a gadget does not specify a constructor we can simply use the default or void constructor (e.g. var gadget = new FooGadget()).

Once the gadget has been created the gadget needs to be informed it has been placed onto the page. The current proposal enables script block to be defined as follows:

<javascript location="beforeContent | afterContent | atEnd">
    ...JavaScript logic...
  </javascript >
  • How does this code retrieve the gadget instance? Do we eval the script block in the scope of the instance?
  • An alternative is to call an onAdd method (if present) on the gadget. Additionally onLoad/onUnload which are called when the page is loaded and unloaded. These methods can be specified in the API metadata for the gadget which are simply executed at the appropriate time. NOTE: We want to keep the requirements as simple-as-possible regarding metadata, therefore a simple instance base mechanism should also be possible.
   <javascript location="beforeContent">
       __GID__.onAdd = function() {
     }
  </javsascript>

Gadget Destruction

Some gadgets may need to know then they have been removed from the page, therefore a callback mechanism should be used as specified in the creation section above, that is, either specify an onDelete method in the class metadata or use an instance base approach as follows:

  <javascript location="beforeContent">
      __GID__.onDelete = function() {
    }
 </javsascript>

Page Load/Unload Events

Each gadget library specifies a mechanism for registering page loaded and unloaded event (e.g. google _IG_RegisterOnloadHandler()) therefore existing mechanisms will continue to function. Additionally it had be proposed to provide an OpenAjax mechanism for registering interest in these page lifecycle event, OpenAjax.widget.registerOnloadHandler(). We should also provide:

  • OpenAjax.widget.registerOnUnloadHandler()
  • The ability for specify callback function closures on a widget instance so that the above callbacks execute under the scope of the widget. For example:
    OpenAjax.widget.registerOnLoadHandler( OpenAjax.widget.hitch(myWidgetInstance, myWidgetInstance._onLoadHandler));

...or... simply try to invoke the an onLoad/onUnload method if an object is passed to the registration methods.


Translations

The translation into different locales will be done using a simple macro style expansion mechanism that is employed during the widget preparation phase. SEN: The localization proposal is located here OpenAjax Metadata Specification Localization and employs a simple name/value scheme in the translation. NOTE: The scope of the localization information is strictly for the Widget metadata NOT necessarily the widget itself.


CSS

Mixing widgets from a variety of toolkit pose interesting challenges especially if each widget uses different styles. We have the following requirements:

  • Widgets need to be able to load style sheets dynamically. Do we expand the WidgetWrapper with a service factory protocol that enables dynamically loading style sheets?
SEN: The current proposal uses the require tag to specify CSS files, the widget writer simply specifies the CSS references and does NOT require the widget writer to worry about loading the stylesheet.
<require src="YUI/build/button/assets/skins/sam/button.css" type="css" includeAssetReference="true"/> 
SEN: Note there are no provisions for stylesheet name collision, for example Ext and Dojo widgets tend to modify the container's style (e.g. html & body tags), which leads to unexpected behaviors.
  • The style sections can be defined in the content section of the widgets. SEN: Style sheets are specified in the required list of the widget NOT in the content section, this should be OK.
  • Do we formalize the dependencies on style sheets so that an implementation can optimized/redefine as appropriate? The current proposal enables server-side optimization across and within single widget loading (i.e. html inline and sandboxed via IFRAME).
  • Do we support any type of 'themes' across widgets?
Personal tools