Building a fully-featured, useful, and
Develop in Firefox with Firebug
Don’t go “whole hog” Specify
Your application should make liberal
Consider Data Pipelining Data Pipelining
is the best way to prepare data you need before it even loads in the browser. Use it to fetch social data from a container or from your remote servers. It works best for data that you always know you need in a view or subview, as conditional logic is difﬁcult to support with it. Start by including it as a feature in your gadget spec.
Within your views, include script
Every pipelined request you labeled
with a key is now available by retrieving a dataSet from the dataContext. If you’re working with JSON structured data, you can work directly with your results. Retrieving results from Data Pipelining is easy!
Say goodbye to a waterfall
of callbacks. () ck ba all k() cC () bas k fu ac allok n ) k() () llb ksCBo () k( cti Ca Boo t ack ac Ge ac llb ack on ks Get onksCallb al)lb ) n on Ca llb ck( oo C( on o o basck oks sCa llba tB nctio tBo on nG sCa cei allok Ge fu Ge fu onG t ksCBo k () o ook tB oo ack e on tion fun etBoo Get t tB back() Callb Ge tB Bo nct etB on func ksCall onG on nGe oo on nG oks cti o i etBoo tion no ks on on on o k n onG tBo fun func ctio sC cti cti ion C fun functio () Ge all allback ion on fun fun unct allb opleC b ct ac f n onPe a fun ck functio () k ()
Data Pipelining has what you
need. • os:HttpRequests can re-use canvas parameters in requests. • Pipelining tags are executed in sequence and can reference data fetched by a previous tag • os:HttpRequest has all the capabilities of gadgets.io.makeRequest, including signed authorization • People Resource tags support specifying speciﬁc ﬁelds and building collections. • Each dataSet object allows for error checking. • Separating concerns with canvas subviews means that each of your subviews can have their own Data Pipelining requests, resulting in more efﬁcient loading strategies. But wait, there’s more!
OpenSocial templates mean even less
code. OSML templates are most often compiled server-side, binding the results from Data Pipelining requests into placeholders within relevant templates. OSML allows for iterating over a collection and conditional logic within a template using JUEL-like expressions, in addition to depending on the existence (or absence!) of data. Templates can exist inline within the gadget spec, or be loaded from an external Template Library ﬁle. To get started, include the opensocial-templates feature in your gadget spec.
Suppose you requested some basic
information on the OWNER of a canvas page, like their name, thumbnailUrl, and proﬁleUrl. Additionally, suppose you retrieved information about a book in JSON format from your servers based off a view parameter called bookId.You expect results to contain a title, url, and thumbnailUrl. Your Data Pipelining tags would look something like:
Now we’re going to write
a OSML template that renders the book we fetched from our server along with details about the owner of the current canvas page. Since we require a book & owner object to continue, we set a require attribute on our tag equal to the comma-separated list of “keys” we are need to render. Our OSML tag to render a book with accompanying owner information might look something like:
Pre-production checklist Before you put
OAuth Seems like all APIs
these days require some knowledge of OAuth. OpenSocial is no exception, though it’s easier than you think. Whenever you make a signed request from the container to your server, the request will be signed using two-legged OAuth. Whenever you make a signed REST request to our container for social data, you will also sign the request using two-legged OAuth. In the case of LinkedIn, incoming requests to your server will be signed and you will validate the request using a public certiﬁcate. When making API calls over REST, you will sign the request using your issued consumer secret. In two-legged OAuth, there is no concept of an access token or oauth_token parameter. When representing a member while making REST requests, you specify an additional parameter called xoauth_requestor_id with the value set to the member id of a user who has granted your application permission. The best way to validate requests is to use one of the OpenSocial client libraries developed by the OpenSocial community and available at http://bit.ly/aJ44UG.
Parting words of advice. Read
OpenSocial API documentation voraciously. Don’t be afraid to ask for help. Experiment with different approaches while you are in development. Once you’ve settled on an architecture, it’s difﬁcult to change. Building an OpenSocial application is also an opportunity to build a rich API for your servers. If you’re primarily primarily HTML from your servers, consider wrapping the it in JSON hashes to provide your gadget metadata that can assist you in assessing application state. Use other OpenSocial applications as examples of what is possible, especially if you can ﬁnd a parallel to the type of application you are building. When designing the look & feel of your application, try to repeat design patterns utilized by the container you will deploy to. Don’t abuse virality options like activity streams & messaging. Each viral event in your app should correspond to a direct user action. It’s not interesting or valuable to a user’s connections that your app was installed. It is interesting to discover what users are doing with your application.