So, basically what you're saying is that you're dropping support for UserPrefs in URL content type gadgets. You should make this clear in the documentation: http://code.google.com/apis/gadgets/docs/reference.html#Userprefs_Ref
On Apr 23, 7:51 pm, Rob Russell <[email protected]> wrote: > The gadgets API is a Javascript API. An API is meant to be an abstraction on > top of a system, so the details like where the UserPrefs are stored ideally > shouldn't matter to the gadget. I understand that the API doesn't cover all > cases perfectly but it is the only thing that we can reliably test. > > As a gadget developer, putting the code to access preferences in Javascript > then calling your server side script from there has a couple benefits. > First, you have an extra point for debugging and troubleshooting between > your gadget and Google servers. Second, your gadget can be cached by Google > for faster initial delivery to the user. > > Caching on Google can be helpful in different ways depending on your gadget > architecture. Take a structure like this for example: > <Module> > ... > <Content type="url" href="example.com/ssgadget.php"> > > Then ssgadget.php includes some Javascript inline and some gadget code. Some > of the page is changed to suit the UserPrefs. When the user loads their > iGoogle page, the browser requests all the gadget resources from example.com > . > > Now consider restructuring this to get some benefit from Google caching it: > <Module> > ... > <Content type="html"> > <script> > (some code to put up a "loading..." message) > ... > (big chunk of Javascript that used to live in ssgadget.php) > ... > (snippet to collect prefs) > gadgets.makeRequest("example.com/gadgetservice.php",...) > ... > (replace loading message with content from server) > > This modified gadget is still initially served from your server (at > example.com/gadget.xml, for example) but it will be cached by iGoogle. The > results of gadgetservice.php will not be. This means: > 1. There can be a significant amount of script pulled out of the earlier > ssgadget.php which can be served from the cache on iGoogle, saving you > bandwidth. > 2. Since the second gadget is served from iGoogle's cache, it will likely > load faster in the user's browser. What the user sees is a loading message > but that can be better than an empty box waiting for everything to come from > example.com. > 3. It's easier for the developer to test changes to gadgetservice.php since > they can now do more development and testing independent of iGoogle. > > Rob Russell > Google Developer Relations > > > > > > On Fri, Apr 23, 2010 at 11:08 AM, Nick <[email protected]> wrote: > > Please support them in both the query string and fragment in the > > future. This will go along way, for customers who can't modify the > > gadget to include JavaScript easily. > > > On Apr 23, 1:55 pm, "Rob Russell (Google)" <[email protected]> > > wrote: > > > Summary: > > > UserPrefs are back in the query string right now. They may move to the > > > URL fragment again. If you have gadgets which rely on the position of > > > the UserPrefs in the URL, please update them to use API functions. Use > > > gadgets.Prefs or _IG_Prefs as appropriate for your gadget. > > > > A little more detail: > > > As you probably already realize, iGoogle is a large piece of software > > > with a lot of moving parts. We work hard to maintain the code and to > > > improve it for developers that use our APIs and end users on iGoogle > > > in a number of ways. > > > > Launching new features and maintaining existing ones requires frequent > > > changes to the software which happen on an on-going basis. The change > > > which moves UserPrefs from the query string to the URL fragment is > > > only one of several changes that can depend on each other and are all > > > released together. The release which included moving the UserPrefs has > > > been reverted for the time being. > > > > 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%2Bunsubs > > [email protected]> > > . > > > For more options, visit this group athttp:// > > 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%2Bunsubs > > [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 > athttp://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.
