View Level Features Proposal

Owned by Andy Smith
Last updated: Mar 22, 2011 by Matthew MarumVersion comment
4 min read

Scope of change: Small
Champion Name: Andy Smith(IBM), Matt Marum(IBM)
Spec Editors: Matt & Andy
Ref implementation: 2 Weeks effort by Matt to develop patch for Shindig  (https://issues.apache.org/jira/browse/SHINDIG-1492)

Background

Features are currently loaded as a top level component in the Module Prefs today independent of the particular view requested by the container.    There are use cases where additional container specific views may be introduced to support mobile and tablet environments.  It's important to provide a capability for application developers to limit the features that may be required by their application in these views.  In some cases, the specific view my not require all of the OpenSocial features, in others a container may want to introduce alternative features for different environments. 

The /ModulePrefs/Preload already has a views attribute that allows resources to be preloaded only for selected views. This makes it the model for the proposed changes to the OpenSocial 2.0 specification.

Example Use Cases

Example 1

Container supports the following jQuery features:

  • jquery-1.4.4
  • jquery-mobile-1.0
  • jquery-ui

Gadget developer wants to leverage the jquery-ui for canvas, home, and profile.  For a custom mobile view the developer wishes to use the jquery-mobile feature.

Example 2

A gadget developer has a similar environment to that listed above.  In this case the canvas, home, profile mode require the pubsub2 feature for gadget communication.   For the mobile environment (light-weight container), the developer doesn't need to leverage any of the pubsub features because it does not have the same mashup characteristics as other deployment scenarios.  In this case the developer wants to exclude this library and limit the additional overhead of loading the pubsub2 feature

Example 3

A gadget developer has developed a gadget that uses significantly different views that were designed with different environments in mind. In designing these different views, different strings were used in the UI that need to be localized. If the developer was using /ModulePrefs/Locale elements to handle localization, then all localized messages will be loaded for all views of the gadget even if they aren't used at all. In this case, the gadget developer wants to exclude the additional overhead of loading messages that are not needed.

Proposed Spec Change

We propose to add an optional views attribute to the /ModulePrefs/Require, /ModulePrefs/Optional, and /ModulePrefs/Locale elements. The views attribute can be multi-valued if you provide a comma separated list of views. For example, you could apply the same Required feature to multiple views using view="view1, view2, view3". This is the same way multiple views are specified elsewhere in the Gadget XML.

For /ModulePrefs/Require and /ModulePrefs/Optional, containers SHOULD only load these features when an appropriate view is being rendered. Require and Optional elements that do not specify any views will be loaded for all views of the gadget as they do currently. This is consistent with the behavior of Preload which already has @views in the current specification.

  <Module>
    <ModulePrefs>
      <Require feature="opensocial-1.1" />
      <Require feature="pubsub" views="default, canvas"/>
      <Require feature="mobile_feature" views="mobile"/>
      <Require feature="views" />
      <Preload href="http://www.example.com" views="default"/>
    </ModulePrefs>
    <Content type="html" view="default, canvas">
      <![CDATA[ regular gadget content ]]>
    </Content>
    <Content type="html" view="mobile">
      <![CDATA[ mobile gadget content ]]>
    </Content>
  </Module>

For /ModulePrefs/Locale, containers will continue to follow the existing rules for selecting a Locale defined under Localization in the existing specification. To those rules, we add that the container SHOULD select a Locale that matches the current view over any other Locale.

<Module>
  <ModulePrefs>
    <Locale lang="en" messages="http://example.com/hello/en_ALL.xml"/>
    <Locale lang="en" messages="http://example.com/helloMobile/en_ALL.xml" views="mobile"/>
  </ModulePrefs>
  <Content type="html">
    <![CDATA[
      <h1>__MSG_greeting__</h1>
    ]]>
  </Content>
  <Content type="html" view="mobile">
    <![CDATA[
      <h1>__MSG_mobileGreeting__</h1>
    ]]>
  </Content>
</Module>
Feature Version conflicts

With this proposal, it becomes possible to declare conflicting versions of features that need to be resolved by the container when rendering a view. This situation can occur when the same feature is specified at a global scope (no @views specified) and at a view scope (@views specified) but with differing @version values. In these cases, Containers SHOULD use the Feature version listed in the Feature declaration that explicitly lists the View being rendered. A gadget developer can easily avoid this situation by being explicit about which views require which features.

Feature Parameter conflicts

With this proposal, it is possible for a gadget developer to declare the same version of the same feature multiple times for the purpose of supplying particular views with different Feature Parameters. When processing a gadget or responding to requests for feature parameters (gadgets.util.getFeatureParameters), containers SHOULD select the parameters that match the current view over any other parameters.

  <Module>
    <ModulePrefs>
      <Require feature="pubsubFake" views="default"/>
      <Require feature="pubsubFake" views="mobile">
        <Param name="isMobile">true</Param>
      </Require>
      <Require feature="views" />
    </ModulePrefs>
    <Content type="html" view="default">
      <![CDATA[ default gadget content ]]>
    </Content>
    <Content type="html" view="mobile">
      <![CDATA[ mobile gadget content ]]>
    </Content>
  </Module>
Other /ModulePrefs/* elements

We've considered extending the view level capability to /ModulePrefs/Link and /ModulePrefs/OAuth, but were not able to come up with compelling use cases. Community input of use cases for adding view level support to other elements is welcome.  This can be done via e-mail to opensocial-and-gadgets-spec@googlegroups.com. Refer to the existing discussion thread below.

Proposal Discussion

https://groups.google.com/d/topic/opensocial-and-gadgets-spec/v93sX_NrVh8/overview
http://code.google.com/p/opensocial-resources/issues/detail?id=1133