Hi Rob,
Do you guys seriously just break API's for the sake of breaking them.
I was forced to move from the type="html" to type="url", about a year
ago because your proxy server was constantly causing issues when
pulling feeds.
Why is it that you assume every solution can be accomplished with the
Google model of everything JavaScript. Now to implement a large
JavaScript library to handle AJAX requests. The size of this
JavaScript library is going to take a lot longer to download than my
current server-side gadget does. And not to mention I still have to
hit my backend server to get the same information again. So congrats
these "improvements" are actually slowing my gadget down.
That is why I am going to stick with this method for now.
<script type="text/javascript">
if (window.location && window.location.hash) {
var hash = window.location.hash;
window.location.search = "?" + hash.substring(1);
}
</script>
Nick
On Apr 21, 4:26 am, Rob Russell <[email protected]> wrote:
> Hi Edouard,
> The change is definite, it doesn't affect the API. The legacy _args() API
> and the current gadgets.Prefs() API still work as they always have. It makes
> sense that server side code would look at the parameters since there isn't
> an API for server side code. As I said earlier, we'd normally announce this
> sort of change earlier.
>
> Specific gadgets which are identified by the urls authors give here will be
> handled separately so that they continue to receive the older user prefs url
> convention until May 4.
>
> Your response to change your gadgets to use JS and Ajax loading sounds like
> a good plan. I think (but haven't built code to try this yet) that it should
> give a better user experience. The reasoning being that your loader gadget
> can be small and cacheable. This way it's served quickly and renders
> quickly. The delay while loading content from your server via Ajax shouldn't
> be long but it doesn't delay loading the users page.
>
> You may also want to double check any analytics code and stats software
> you're using to ensure that any changes to urls and parameters are
> reflected.
>
> Regards,
> Rob Russell
> Google Developer Relations
>
>
>
>
>
> On Wed, Apr 21, 2010 at 1:00 AM, Edouard Fattal <[email protected]> wrote:
> > Hi Rob,
>
> > In my case, because I could not afford waiting for a solution coming from
> > Google, I immediately moved all my gadgets to JS/Ajax loading instead of
> > server-side handling.
>
> > I am still surprised by this important change without any notice. How can
> > the team decide such changes without imagining the consequences for the
> > gadgets?
>
> > All I need now is consistency from the API. Are we sure that this change is
> > definite?
>
> > How will you now distinguish the difference between content and URL
> > gadgets? They are now very similar because they will both load content that
> > depends on user prefereces through Ajax , except that content gadgets are
> > cached by Google servers and that content gadgets have to deal with
> > cross-domain concerns.
>
> > --
> > 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.
