shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mack, Trevor M." <tm...@mitre.org>
Subject Strangeness gadgets.view
Date Thu, 19 Jul 2012 22:13:31 GMT
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 | tmack@mitre.org

Mime
View raw message