The iframe url is created by the server and passed by the metadata response,
the common container use it and update the url: add user perfs, view, token
etc.

-Ziv

On Mon, Jan 3, 2011 at 10:41 AM, Ryan J Baxter <[email protected]> wrote:

> I sent the below email over the holidays but didn't hear anything.
> Resending now that more people are probably back from vacations etc.
>
> -Ryan
>
> Email: [email protected]
> Phone: 978-899-3041
> developerWorks Profile
> ----- Forwarded by Ryan J Baxter/Westford/IBM on 01/03/2011 01:40 PM -----
>
> From:   Ryan J Baxter/Westford/i...@lotus
> To:     [email protected]
> Date:   12/23/2010 09:09 AM
> Subject:        Constructing the iFrame URL
>
>
>
> 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
>
>
>
>

Reply via email to