shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Baxter <>
Subject Re: Strangeness gadgets.view
Date Fri, 20 Jul 2012 06:09:44 GMT
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)


On Thu, Jul 19, 2012 at 6:13 PM, Mack, Trevor M. <> 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
> --------------------
> <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
> --------------------
> 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 |

View raw message