No, I should have put more data in the original post. Now that I go back and look at it I left the question very open ended. Yes, your answer is perfect. I was wondering if the container had to refetch the gadget when I switch to canvas mode or if was handled in the gadget by my switching the currentView. I think I am finally starting to get the roles and responsibilities of each piece better now.
I have been referencing partuza a bit but I seem to be unable to find some items. Probably because I have limited exposure to PHP and I am not the sharpest tool in the shed. Thanks for the help On 2/22/09 1:13 PM, "Chris Chabot" <[email protected]> wrote: pps, for shindig / container development related questions this is actually the best list; Since in the original email you didn't quite mention if you were developing the container or the gadget side of things, and i kind of assumed views would 'just work' from a shindig point of view, I guessed you were asking for the gadget pov, my mistake, sorry :) On Sun, Feb 22, 2009 at 10:04 PM, Chris Chabot <[email protected]> wrote: As long as the gadget is coded correctly, making shindig render the canvas view is as simple as appending &view=canvas to the iframe URL. For example the iframe url would look something like (bits in caps is what you would fill in your self, oh and make sure to also append the user preferences and optional params from requestNavigateTo to this url as well) : http://<SHINDIG>/gadgets/ifr ?synd=<YOURCONTAINERNAME> &container=<YOURCONTAINERNAME> &viewer=<VIEWER ID> &owner=<OWNER ID> &aid=<APPLICATION ID, CAN BE NUMERIC OR GADGET URL> &mid=<MODULE ID (AKA '4TH GADGET ON THIS PAGE') &country=<COUNTRY CODE> &lang=<LANG CODE> &view=<INSERT VIEW NAME HERE: profile, home, canvas, preview> &parent=<CONTAINER URL> &up_<FOO>=<BAR> &st=<LONG ENCRYPTED TOKEN> &v=<CACHE BUSTING MD5 OF THE GADGET XML> &url=<URL OF GADGET'S XML FILE> #rpctoken=<RANDOM UNIQUE NUMBER> How internally you want to implement views (have different url's per view, or some query param, etc) is really completely up to you, as long as you write some javascript and hook it up to the requestNavigateTo rpc call, in other words do something like: function myRequestNavigateTo(view, opt_params) { // do magic here } gadgets.rpc.register('requestNavigateTo', myRequestNavigateTo); A simple example of that can be found in partuza's implementation: http://code.google.com/p/partuza/source/browse/trunk/html/js/container.js Since you didn't give us a whole lot of background, I'm hoping this generic answer is useful, but if not please share a bit more information about what your attempting to do and how, so we can respond in more detail too :) -- Chris On Sun, Feb 22, 2009 at 9:51 PM, David Benge <[email protected]> wrote: As always thanks for the help Chris. The article you sent is nice but it talks about the view from the gadget developers point of view. I think my issue is when I switch to canvas view in the display I am not asking the gadget to be rendered for that new view. Is there a list for Shindig implementers / container implementers? It would be great to have a place to discuss and reference items related to these topics. On 2/21/09 1:54 AM, "Chris Chabot" <[email protected]> wrote: Hey David, The shindig-dev list is really intended for shindig (server) development, and not so much for general OpenSocial (client side) support. There are a number of googlegroups around this topic though. Have you looked at the OpenSocial tutorial btw? It's last paragraph is about how to use views: http://code.google.com/apis/opensocial/articles/tutorial/tutorial-0.8.html#views If something doesn't work with that code, then it might be worth knowing what container your trying to run your gadget on. -- Chris On Sat, Feb 21, 2009 at 2:43 AM, David Benge <[email protected]> wrote: > Can someone point me to a post or thread on how to properly implement > views? > I seem to always have a undefined gadgets.views object even with the > feature included. > > Thanks >
