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

Reply via email to