[OpenAjaxIDE] Ideas on distinguishing between widgets and gadgets

Kin Blas jblas at adobe.com
Wed Aug 27 11:31:28 PDT 2008

I think that before we go making a decision on how to differenciate
between UI Component, Gadget, and Mashable Gadget that we do some
"sharing" and "prototyping" of meta data files.


Yesterday I asked if someone could show us all how one would turn a UI
Component into something that was mashable ... I'd also like to see an
example that takes a gadget and also makes it mashable.


What I'm interested in is seeing if this theory can hold:


-          The Widget Metadata File (WMD) should express how a UI
Component or Gadget can be inserted into a page. This includes any
markup, JS code, and assets.


-          The code/markup inserted into a page for a given UI Component
or Gadget should work within a page regardless of whether the page
contains static content or sets up an mashable environment. If no
mashable environment is available, the UI Component or Gadget operates
standalone, or as someone in yesterday's meeting mentioned, as an
"island". In order to support this, it may be necessary for the WMD
author to include JS code that checks for the presence of the OAA
sanctioned mashable interface, and if present, register itself with it
and any other pub/sub set up it needs to perform. Another option here is
that if a mashable environment is not present, that this widget
invokes/starts up the environment it needs. This would alleviate the
need to modify an IDE so that it can distinguish between a
mashable/non-mashable widget.

The big point I want to make here is that the code/markup that is
inserted here is markup/code that will be invoked in the browser
run-time environment, *NOT* within an IDE, so no assumptions about IDE
implementations should be made in this code.


So now a question I'm not sure about:


-          Is it possible for Mashup IDEs to leverage the exact same OAA
sanctioned mashup interface to communicate/modify the mashup widget
during *Design Time* as is used during the *Run Time* when running the
page in a browser? I know that the Mashup Editor reference
implementation runs in a browser, but what I mean by "Run Time" here is
the resulting page, produced by the editor, that is deployed and seen by
other users in their browsers. 


I'm hoping the answer here is yes, which would mean that the exact same
"mashup discovery" code within the WMD can be used to allow a mashable
widget, invoked in real-time within a Mashup Editor IDE, to discover and
communicate with the Mashup Editor.


--== Kin ==--



From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On
Behalf Of Jon Ferraiolo
Sent: Wednesday, August 27, 2008 3:16 AM
To: ide at openajax.org
Subject: [OpenAjaxIDE] Ideas on distinguishing between widgets and


As I remember from yesterday:

(1) We agreed that a widget probably needed special metadata, such as a
new attribute or some particular new usage of the <require> element, to
say whether or not it is a "gadget" (i.e., where the term "gadget" means
suitable for mashup environments)

(2) When I asked whether which of the following we would support of
basic widgets, mashupable widgets, or widgets that could work as either
basic or mashable widgets, we decided that there would only be two
options: basic widgets and mashable widgets.

(3) We decided that both kinds of tools (i.e., IDEs and mashup tools)
would support both types of widgets (i.e., basic and mashable). 

(4) For IDEs to support mashable widgets, one option that looked
attractive was for OpenAjax to supply a reference implementation of
either a JavaScript file or a metadata file. 

Before proposing solutions, does the above match what everyone else
remembers? Incidentally, I am highly positive about this general
direction of distinguishing between basic widgets and mashable widgets. 

I will do a little cheerleading here to point out that we should be able
to achieve this distinction with only small changes to the existing
specification. After doing an inventory of the widget markup we have so
far, here are things that apply to basic widgets: <widget>, <category>,
<content>, <javascript>, <require>, <properties>, <option>, <include>,
descriptive metadata (including icons), compatibility metadata, property
transformations (@@foo@@) and localization transformations (%%bar%%). I
also think __WID__ applies to basic widgets, but we probably need
further discussion on that one. I will point out that these "basic
widget" features represent the vast majority of our current widget

Here are the small number of extra things within the current spec that
only apply to mashable widgets:

* <topics>/<topic> elements
* The 'publish', 'subscribe' and 'topic' attributes on the <property>
* Widget APIs (getConnectionHandle(), registerCallback(),
getPropertyValue(), ...)

(Am I missing anything?)

Here is a sketch of how we might proceed:

(1) Add the following feature to our XML format:

<require type="feature" name="OpenAjax.mashupwrappers"/>.

This tells IDEs that it needs to insert extra stuff into the HTML page
so that the widget won't crash when it attempts to call the widget APIs.
By using the feature approach, we allow the tool greatest flexibility in
how to deliver the required functionality (versus pointing to a
particular JavaScript file).

(2) Provide an open source JavaScript reference implementation for the
mashup wrappers. This will allow IDEs an easy path where they simply add
some <script> elements to the HTML page that point to the JavaScript
files that we provide. Our open source reference implementation for IDEs
would only support OpenAjax Hub pub/sub within a single browser frame
using Hub 1.1 APIs. Therefore, reference implementation would:

* support connHandle = wrapper.getHubConnection()
* support connHandle.publish()
* support connHandle.subscribe()
* listen for the document load event and invoke any callbacks registered
via wrapper.registerCallback('load', ...);
* return null for most everything else in our Widget APIs

(3) IDEs could choose to customize the open source we provide (or
replace it entirely) to provide additional functionality (e.g., resizing
API support). Mashup tools almost certainly would provide their own
mashup wrappers.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080827/742fd422/attachment.html 

More information about the IDE mailing list