What about on the Shindig wiki? There is actually already a page about metadata https://cwiki.apache.org/confluence/display/SHINDIG/Shindig's+metadata+call . However I would like to see whatever documentation you can provide about the common container and what it can do on the wiki as well.
Thanks for your help. -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Michael Hermanto <[email protected]> To: [email protected] Date: 01/04/2011 04:02 PM Subject: Re: Constructing the iFrame URL On Tue, Jan 4, 2011 at 12:54 PM, Ryan J Baxter <[email protected]> wrote: > 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. Right, specifying which metadata desired is one advantage. Another is the inclusion of expired times, which tells common container JS when to expire client-side gadget metadata cache. Common container JS itself does more than the shindig.container, like gadget preloading, security token refresh, gadget navigation latency reporting. > Should one method be deprecated in some way? Yes, shindig.container should be deprecated. > 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. > Not really documented, but I agree it should be better documented. I started this within Google and we have docs. I can bring those into Shindig. Suggest a place, where I can do this? Thanks. > -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 > > > >
