Here <https://cwiki.apache.org/confluence/display/SHINDIG/Common+Container>is a start, with a new page just for common container. Please take a look. Took me some time to reformat the texts, as rich-text copy-paste wasn't acting friendly. :(
On Tue, Jan 4, 2011 at 1:17 PM, Ryan J Baxter <[email protected]> wrote: > 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 > > > > > > > > > > > >
