Really? I was never aware of this. I recall in the legacy api using simple variable substitution to pass the preference value to a type URL gadget as a query string. It was something along the lines of "http://something/gadget.php?query_param=__UP_name__"; where the "__UP_name__" got replaced with the preference value. This and the library injection method I mentioned were the ones I was familiar with through the documentation.
On Apr 24, 4:59 pm, Gavin McDonald <[email protected]> wrote: > 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 > 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.
