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