Thanks for the suggestion and the offer Ben. I also looked at makeRequest
and I think it's a good solution for many users. When using makeRequest
remember the request to your server will come from Google instead of
directly from the user's browser, so it's important to remember that cookies
won't be sent in this case. If a gadget has corresponding server side code
that does need data from cookies, they could still be read the data in
Javascript and pass it along through makeRequest in a different way.

Ben's code also has clear error handling for the response from makeRequest.
It's good to check the received information - it makes development easier
and helps debug problems that arise later on.

Rob Russell
Google Developer Relations


On Thu, Apr 22, 2010 at 11:38 AM, Ben Curtis <[email protected]> wrote:

>
> My gadget for Chess.com uses an enhanced version of this technique, which I
> think may help a couple people out there with complex gadget needs.
>
> Our server delivers the same "pages" to iGoogle as we do to Facebook. In
> Facebook, due to the Javascript sandboxing, we need to be in an iframe. In
> iGoogle, due to the Javascript Open Social API (a lot like the set prefs
> code), we need to be embedded in the gadget's domain and not use a remote
> iframe. I achieved this duality by creating a gadget that calls the page
> with makeRequest and then outputs the response into an iframe without a
> domain created by the javascript. This is effectively a Javascript-enforced
> proxy browser.
>
> Why not dump it into a div? Because a lot of our legacy Javascript
> (including all the ajax mumbo-jumbo our server framework spits out) assumes
> its in its own window object.
>
> Complex and twisted, yes. But it works. It's probably more complex than
> needed for most people. On the off chance that someone reading this (now or
> in the future) needs something like this solution, here's the gadget
> definition:
>
> http://ig.hosted.chesscomapps.com/api/gadget_def.php
>
> Naturally, I can't support this as sample code, and I make no pretenses
> about it's readability or elegance. But if someone finds they need something
> like this, I'm the only one I know of with this solution, and I'm happy to
> share.
>
>
>
>
> On Apr 22, 2010, at 1:34 AM, Rob Russell wrote:
>
>  That's true, using set prefs from script in the inner iframe won't work as
>> far as I know.
>>
>> If a gadget also sets preferences then they may be able to read the
>> content of the page and place it inside a div. This should allow access to
>> the API to set preferences. The thing is the content of the page may include
>> a root html element which could cause issues on some browsers when inserted
>> in a div. So if that's the case developers might want to tailor the server
>> side script that delivers the page.
>>
>> Rob Russell
>> Google Developer Relations
>>
>>
>> On Thu, Apr 22, 2010 at 1:19 AM, Edouard Fattal <[email protected]>
>> wrote:
>> Be careful, this method can only help to read the preferences but the JS
>> code in the iframe will be unable to modify the preferences.
>>
>>
>> 2010/4/22 Gavin McDonald <[email protected]>
>>
>> Rob,
>>
>> This is an acceptable method to restore service to my broken gadget, and
>> thanks to your team for being proactive to find a solution.
>>
>> Regards,
>> -G
>>
>> Gavin McDonald
>> EVI Logistic Enterprises
>> 604-313-3845 - VE7HXR
>>
>>
>>
>> On Wed, Apr 21, 2010 at 7:02 PM, Rob Russell <[email protected]>
>> wrote:
>> I spent some time today, with the help of other developers on the iGoogle
>> team, coming up with a way to adapt an arbitrary gadget that relies on the
>> way user prefs used to be supplied with the url in type="url" gadgets. A
>> gadget ideally only needs the gadget API, and shouldn't rely on the way
>> iGoogle sends (or doesn't send) parameters in the URL query string.
>>
>> Keep in mind that what I'm suggesting is just one way to adapt such a
>> gadget, it's up to individual gadget developers to detemine what works for
>> them. I have used this to adapt one of the reported gadgets and it seems to
>> work fine.
>>
>> The crux of the idea is that instead of supplying an external page to
>> wrap, we use a type=html gadget and request the page that we want wrapped
>> after the gadget loads. The wrapping gadget will be cached by iGoogle. You
>> can consider this code a template and adapt it if you'd like to include a
>> loading animation or message for the user in case your server takes some
>> time to respond.
>>
>> I've tested this with sample data in IE6 on Windows and on Firefox. It is
>> just an example though and I encourage anyone that sees room for improvement
>> to chime in.
>>
>> The UserPrefs elements are the same as for the existing Content type=url
>> section, as are the Module and ModulePrefs elements.
>>
>> In the Javascript, the wrappeduserprefs variable is an array of the values
>> of name attributes from the UserPref elements. So for this pretend gadget,
>> it has prefs myname and mycolor. The type of the UserPref doesn't matter.
>> The wrappedpage variable is the url of the page that your Content type=url
>> gadget pointed at - that is the value of the href attribute on the Content
>> element.
>>
>> If your server code doesn't need the "up_" prefix on the parameter name
>> then change (most will but it could be a chance to clean up some server side
>> cruft)
>>      params["up_"+userprefs[key]] = prefs.getArray(userprefs[key]);
>> to
>>      params[userprefs[key]] = prefs.getArray(userprefs[key]);
>>
>> Here's the code
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <Module>
>> <ModulePrefs title="example url iframed" />
>> <UserPref name="myname" display_name="Name" default_value=""/>
>> <UserPref name="mycolor" display_name="Color" default_value="Red"
>> datatype="enum" >
>>  <EnumValue value="Red" />
>>  <EnumValue value="Blue" />
>> </UserPref>
>> <Content type="html">
>>  <![CDATA[
>>  <script type="text/javascript">
>>  var wrappedpage = "http://example.com/mygadget.php";;
>>  var wrappeduserprefs = ["myname","mycolor"];
>>
>>  var prefs = new gadgets.Prefs();
>>  var params = {};
>>
>>  function init() {
>>    for (key in wrappeduserprefs) {
>>      params["up_"+wrappeduserprefs[key]] =
>> prefs.getArray(wrappeduserprefs[key]);
>>    }
>>
>>    document.getElementById("wrapped").src = wrappedpage + "?" +
>> gadgets.io.encodeValues(params);
>>  }
>>
>>  gadgets.util.registerOnLoadHandler(init);
>>  </script>
>> <style>
>>  body {
>>  margin: 0;
>>  padding: 0;
>>  overflow: hidden;
>>  }
>> </style>
>>  <iframe src="" name="wrapped" id="wrapped" width="100%" height="200px"
>> style="border:none; margin:0; overflow:hidden; padding:0;" scrolling="no"
>> frameborder=0 >
>>  </iframe>
>> ]]>
>> </Content>
>> </Module>
>>
>>
>> Rob Russell
>> Google Developer Relations
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "iGoogle Developer Forum" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-gadgets-api%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/Google-Gadgets-API?hl=en.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "iGoogle Developer Forum" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-gadgets-api%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/Google-Gadgets-API?hl=en.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "iGoogle Developer Forum" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-gadgets-api%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/Google-Gadgets-API?hl=en.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "iGoogle Developer Forum" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-gadgets-api%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/Google-Gadgets-API?hl=en.
>>
>
> --
>
>   Ben Curtis : webwright
>   bivia : a personal web studio
>   http://www.bivia.com/
>   v/f : 818 507 6613
>   i.m.: BiviaBen
>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "iGoogle Developer Forum" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-gadgets-api%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/Google-Gadgets-API?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"iGoogle Developer Forum" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/Google-Gadgets-API?hl=en.

Reply via email to