After looking at the code below I was curious about how the common container was making the metadata request, and sure enough it is doing it differently than the old container. Looks like at the end of the day the common container is calling osapi.gadgets.metadata. Which is handled by GadgetsHandler.java. The old, samplecontainer.js, was making a request to gadgets/metadata to get the metadata for the gadgets. This request seems to be handled by JSONRpcHandler.java. The two handlers however never use the same code to construct the metadata response, in fact the JSON is completely different between the two, although for the most part the information seems to be the same. (I am sure this is all old news for everyone, but I am just figuring this out.) I am guessing the preferred method of getting metadata is to use osapi.gadget.metadata and GadgetsHandler.java, is that correct? It seems to have the advantage of being able to specify what pieces of metadata you want, I am sure there may be more advantages. Should one method be deprecated in some way? Are these type of things documented somewhere? It was not clear, at least to me, that there were two methods to do the same thing.
-Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Paul Lindner <[email protected]> To: [email protected] Date: 01/04/2011 04:05 AM Subject: Re: Constructing the iFrame URL The new container uses the iframe from the metadata response -- see below. This method is preferred because it moves much of the burden of constructing these URLs to the gadget rendering server. shindig.container.GadgetHolder.prototype.getIframeUrl_ = function() { var uri = shindig.uri(this.gadgetInfo_[shindig.container.MetadataResponse.IFRAME_URL]); uri.setQP('debug', this.renderParams_[shindig.container.RenderParam.DEBUG] ? '1' : '0'); uri.setQP('nocache', this.renderParams_[shindig.container.RenderParam.NO_CACHE] ? '1' : '0'); uri.setQP('testmode', this.renderParams_[shindig.container.RenderParam.TEST_MODE] ? '1' : '0'); uri.setQP('view', this.getView()); if (this.renderParams_[shindig.container.RenderParam.CAJOLE]) { var libs = uri.getQP('libs'); if (libs == null || libs == '') uri.setQP('libs', 'caja'); else uri.setQP('libs', [ libs, ':caja' ].join('')); uri.setQP('caja', '1'); } this.updateUserPrefParams_(uri); // TODO: Share this base container logic // TODO: Two SD base URIs - one for container, one for gadgets // Need to add parent at end of query due to gadgets parsing bug uri.setQP('parent', window.__CONTAINER_URI.getOrigin()); // Remove existing social token if we have a new one if (this.securityToken_) { uri.setExistingP('st', this.securityToken_); } // Uniquely identify possibly-same gadgets on a page. uri.setQP('mid', String(this.siteId_)); if (!shindig.container.util.isEmptyJson(this.viewParams_)) { var gadgetParamText = gadgets.json.stringify(this.viewParams_); uri.setFP('view-params', gadgetParamText); } return uri.toString(); }; On Thu, Dec 23, 2010 at 6:09 AM, Ryan J Baxter <[email protected]> wrote: > I was debugging the metadata rpc code when I cam across something > interesting, that I don't quite understand. When you request metadata for > a gadget it looks like part of that metadata is the iFrame URL, the URL to > render the gadget. This is URL is constructed in > DefaultiFrameUriManager.java. However, I remembered while debugging the > shindig-container.js code that it also constructs the iFrame URL in it's > getiFrameUrl method. It appears that at least in samplecontainer.js we > ignore the iFrame URL returned in the metadata request and choose to let > shindig-container.js construct the iFrame URL instead. Why is that? Is > one method preferred over the other? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > -- Paul Lindner -- [email protected] -- linkedin.com/in/plindner
