From MemberWiki

Overview

The original proposal from the gadgets task force is located here.

Quoted from the proposal:

A widget may contain several content sections, the content modes supported are:

• view - the default, which specifies the main view to the widget
• edit - OPTIONAL section that specifies the Content used to edit the properties of the widget
• help - OPTIONAL section that specifies the help content of the widget

Below are the attributes of the content section:

• mode - OPTIONAL string specifying the mode of the content section (see Content section above), default value is "view"
• href - OPTIONAL string specifying a URL that returns the content of the widget.
• type - OPTIONAL string specifying how to treat the content contained in the section. Type supported include:
  • html - content is to be spliced inline with the page or assembly canvas
  • url - the href points to the content of the widget, in which case an IFRAME is spliced into the assembly canvas pointing to the widget. NOTE: For url content, the <resource> tags are ignored since the Gadget's content rendering is completely delegated to the URL within its own IFRAME.
  • frame - the content of the section is contained within a IFRAME for security and other runtime related requirements, this is the default

So the triple: mode, type, href specified the exact content and semantics.

Current IDE Metadata

The IDE Widget Metadata specification is currently using the 'type' attribute with the following setting: view|edit|help. The type attribute really maps semantically to the mode attribute from the above snippet.

The current IDE Widget Metadata specification does NOT explicitly include the 'url' type from the gadget proposal. This is an important type for mapping to google gadgets as well it enables developers to quickly offer up existing fragments of content.

The proposal is to use the 'src' property on the content element which points to the site containing the content to be used. When the src is set the content should be untrusted as a general rule.

Given the following sample:

<content type='view' src='http://www.untrusted.com/untrustedcontent.html'/>

processing engines SHOULD NOT trust the content located at the endpoint.

The content for the widget may be displayed in an IFRAME or secondary window if the content is help for example.

When a widget is specified using the src attribute metadata related to requires, javascript (beforeContent, afterContent, atEnd) are ignored because the semantics are undefined.

The canvas must pass property settings to the URL based widget using URL parameters. The name of the URL parameters should follow these rules:

• If the <property> has a urlparam attribute the value of that param should be used
• If the <property> does not have a urlparam the name is created by concatenating "wp_" with the value of the name attribute of the property.

The reference implementation provides a helper JavaScript file that if included in the URL based widget retrieves the encoded properties and wires the widget to the OpenAjax Hub 1.1.

Google Gadgets Views Mappings

Quoted from: [1]

"...A view is a location in a container where a gadget is displayed. Different views have different characteristics. For example, a container might have a view that shows gadgets in a small format, and a view that shows gadgets in full page format..."

Here is an example:

<?xml version="1.0" encoding="UTF-8" ?>
<Module> 
  <ModulePrefs title="Hello World!">
    <Require feature="opensocial-0.7" />
  </ModulePrefs>
  <Content type="html" view="home">
    <![CDATA[
      Hello, small world!
    ]]>  
  </Content>
  <Content type="html" view="canvas"> 
    <![CDATA[
      Hello, big world!
    ]]> 
  </Content>
</Module>

The Google Gadgets (update specification) 'view' attribute maps semantically to the Gadgets Taskforce attribute 'mode' whose values could be 'view|edit|help'.

The current OAAM uses the 'type' attribute as mechanism for tagging the content with similar semantics, so the above example would look like this:

...
  <content type="home">
    <![CDATA[
      Hello, small world!
    ]]>  
  </content>
  <content type="canvas"> 
    <![CDATA[
      Hello, big world!
    ]]> 
  </content>
...

Observations:

• The translation above just does a simple brute force translation.
• For well know google gadgets container should we perform semantic mappings? (for example, 'canvas' == 'view' )
• Should we use QNAMES?
• OAAM currently does not support view concatenation (e.g. view="canvas,home")