OpenSocial Templates

[Evan Gilbert]

Hi everyone - wanted to kick off discussions for creating a standard templating solution for OpenSocial. We've been discussing templates from the beginnings of OpenSocial, however we ended up taking it off of the "minimum subset needed to launch" list. We're now in the process of initial launches and it's time to reopen the discussion.

Templates will not make it into version 0.8 of the spec, but we want to work to get a version of templating in developers' hands very soon. Here's a proposed timeline:

• April 14th. Kick off
  
• April 23rd. Draft proposal submitted to spec group for feedback
• May 7th. Deadline for issues to be raised
• May 28th. Resolution on all issues and spec version 1.0
  
• TBD. Reference implementation

Although the official spec date is May 28th, we anticipate that developers will be able to use a prelease version as a JS library much sooner. Once we've come to a rough agreement on design, we will develop a standalone library that anyone can include using <script src="opensocial-templates.js">.

More detailed discussion of the goals and requirements:

• Overview
  
• Developing OpenSocial applications is difficult.
• JavaScript isn't the first language for most developers.
  
• There is no native templating support in OpenSocial, and templating is an established way to make it easy to generate HTML.
  
• It's extremely easy to have insecure OpenSocial applications. String concatenation is one of the most common ways to write gadgets and almost always leads to XSS holes.
• Developers need a way to to use UI elements and widgets defined by the container.
  
• Gadgets want to be able to draw standard versions of UI elements, from buttons to friend pickers.
• The gadget.skins library allows sharing a few key/value pair style properties with the gadget, but nothing more.
  
• There has been general consensus that we should build a standard templating solution for OpenSocial.
• Requirements
  
• Easy to develop with
• Ability to create templates by copying and pasting HTML and making minor modifications
• Assumption is that this means using markup (but open for discussion)
• Secure
• XSS free unless developers explicitly work around XSS protections
• Use of innerHTML strongly discouraged and may be prohibited
• Capable of creating HTML for most applications
  
• Should be able to create entire UI using templating.
• Binds to data returned from the OpenSocial APIs as well as from custom variables the developer has defined
• Can display HTML elements conditionally
• Can iterate through data and display HTML content for each item in a list
• Plugs into OpenSocial
  
• Can render templates on the client in JavaScript
• Can render at least a subset of templates on the server (required for activity streams and messages, useful for performance)
• Easy to define templates
  
• Can implement a template definition using other templates. I.e.: A friend picker template might use the standard button template.
  
• Can implement a template definition using JavaScript. This might only be available for library writers, but many common UI elements will require significant JavaScript functionality to build.

[Reinoud Elhorst]

+1 on the idea to get templates roling!

A couple of notes:

• The auto-html-escaping (or magic-anti-XSS, or whatever you want to call it) is something that needs to be dealt with very carefully. Although to people that do not develop in HTML regularly, might benefit from the extra security, I would think that most gadget developers developed have been developing HTML/javascript for some time, and know how to do things correctly. It might put them off if all their regular tricks result in douple-html-escaping on OpenSocial. I like to compare it to php's magic quotes: the first thing I turn off in any php installation. So I'm not against the auto-escaping, it should be done with considerable carefulness though!
  
• A requirement should be that it allows for i18n of content. We need to be able to separate any business logic from the parts that are language specific; or: business logic should not be duplicated for different languages