in 2008, the "officially supported" way was passing arguments via the query string.
-G Gavin McDonald EVI Logistic Enterprises 604-313-3845 - VE7HXR On Sat, Apr 24, 2010 at 3:56 PM, SerranoABQ <[email protected]> wrote: > I don't think that UserPrefs in type URL gadgets is not being > supported. It seems > to me that people were parsing the URL to get user preferences, when > the "officially > supported" way (at least the one I've seen in the docs) is through the > API Prefs functions. > If some were using an undocumented "feature," then support wasn't > "dropped"; it was > never provided. That it might have worked seems to have been more luck > and coincidence > than by design. > > PS. I've had success with the injection of the API libraries into my > gadget using > the approach given in the legacy API docs (http://code.google.com/apis/ > gadgets/docs/legacy/fundamentals.html#Libs). > both in PHP and pure Javascript and I haven't seen the problems being > reported > here. > > > On Apr 24, 12:00 am, Jeremy Blythe <[email protected]> wrote: > > 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%[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%[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]<google-gadgets-api%[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%[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%[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.
