Trevor, I THINK I know what the problem is...aliasing. I have run
into this before, the getCurrentView function ends up returning a view
that is aliased to something else. In my mind it makes sense to
return view query param in the ifr URL because that is what is
actually being rendered. The JIRA [1] for this issue lacks a good
description. If you wouldn't mind could you add more to the
description field of the JIRA. IF you are feeling really adventurous
maybe you could propose a fix for the issue :) (My suggestion may or
may not be the right approach)
-Ryan
On Thu, Jul 19, 2012 at 6:13 PM, Mack, Trevor M. <tm...@mitre.org> wrote:
> Prior to adding this to JIRA for Shindig I wanted to run it by the community
> to see if anyone else has seen this before or if I might be interpreting the
> OpenSocial API incorrectly.
>
> I created a gadget which declares only one Content type (as outlined below)
> all actual content and structure is being built in JavaScript and/or removed
> for simplicity and security reasons:
>
> --------------------
> <Content type="html"></Content>
> --------------------
>
> Within the JavaScript I have declared to functions as defined below in a
> custom gadget package called "myGroups" as to be able to have domain language
> for accessing gadgets.views.ViewType information:
>
> --------------------
> myGroups.getViewName = function () {
> return gadgets.views.getCurrentView().getName();
> };
>
> myGroups.navigateTo = function (destinationView) {
> var supported_views = gadgets.views.getSupportedViews();
> gadgets.views.requestNavigateTo(supported_views[destinationView]);
> };
> --------------------
>
> Whenever the function myGroups.getViewName() is called the ViewType string
> "profile" is always returned even after the successful request to view the
> gadget within canvas was made with the following
> myGroups.navigateTo("canvas"). Though the gadget rendered in a maximized
> state the string which is being returned for
> gadgets.views.getCurrentView().getName() is still "profile" and not what I
> would expect "canvas".
>
> A workaround / "fix" that I had to do was the following to the gadget.xml
> specification.
>
> --------------------
> <Content type="html" view="canvas,profile,home"></Content>
> --------------------
>
> This leads me to believe that without explicitly requesting multiple views
> Shindig will only assign one view to the single content tag declared. As a
> fairly new (out of practice for 2.5 years) opensocial developer I wouldn't
> imagine this was the intended use of this and that until I state otherwise if
> there is a single content element within my gadget specification then that
> content element should have support for all default views (similar to Android
> / iOS application mentality ... just use the defined view to display on a
> device which the application was explicitly designed/developed for aka
> "tablet syndrome").
>
> Am I just interpreting the views feature incorrectly or does this seem to be
> a problem. I will be making a quick complete gadget to demonstrate this
> problem this evening though wanted to start the discussion to be able to
> include in a potential JIRA ticket.
>
> Environment to replicate problem: Rave version 0.14-SNAPSHOT, Shindig version
> 2.5.0-beta2
>
> --
> Trevor Mack
> Software Systems Engineer (R501), Apache Rave
> Application Development and Maintenance (KICS), R501
> MITRE K-building, 1K136 | (781) 271-7252 | tm...@mitre.org
