You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Mack, Trevor M." <tm...@mitre.org> on 2012/07/20 00:13:31 UTC
Strangeness gadgets.view
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
RE: Strangeness gadgets.view
Posted by "Mack, Trevor M." <tm...@mitre.org>.
Ryan / Staton,
Thanks for the help, I will take some time this weekend to document and provide an example gadget which shows this behavior within the linked to JIRA ticket, #1792.
--Trevor
-----Original Message-----
From: Ryan Baxter [mailto:rbaxter85@gmail.com]
Sent: Friday, July 20, 2012 8:52 AM
To: dev@shindig.apache.org
Cc: dev@rave.apache.org
Subject: Re: Strangeness gadgets.view
Yeah that would help, thanks :)
-Ryan
On Jul 20, 2012, at 6:53 AM, Stanton Sievers <ss...@us.ibm.com> wrote:
> Hi Ryan,
>
> I think you meant to link to this JIRA :)
>
> https://issues.apache.org/jira/browse/SHINDIG-1792
>
> -Stanton
>
>
>
> From: Ryan Baxter <rb...@apache.org>
> To: dev@shindig.apache.org,
> Cc: "dev@rave.apache.org" <de...@rave.apache.org>
> Date: 07/20/2012 02:08
> Subject: Re: Strangeness gadgets.view
>
>
>
> 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 | tmack@mitre.org
>
>
RE: Strangeness gadgets.view
Posted by "Mack, Trevor M." <tm...@mitre.org>.
Ryan / Staton,
Thanks for the help, I will take some time this weekend to document and provide an example gadget which shows this behavior within the linked to JIRA ticket, #1792.
--Trevor
-----Original Message-----
From: Ryan Baxter [mailto:rbaxter85@gmail.com]
Sent: Friday, July 20, 2012 8:52 AM
To: dev@shindig.apache.org
Cc: dev@rave.apache.org
Subject: Re: Strangeness gadgets.view
Yeah that would help, thanks :)
-Ryan
On Jul 20, 2012, at 6:53 AM, Stanton Sievers <ss...@us.ibm.com> wrote:
> Hi Ryan,
>
> I think you meant to link to this JIRA :)
>
> https://issues.apache.org/jira/browse/SHINDIG-1792
>
> -Stanton
>
>
>
> From: Ryan Baxter <rb...@apache.org>
> To: dev@shindig.apache.org,
> Cc: "dev@rave.apache.org" <de...@rave.apache.org>
> Date: 07/20/2012 02:08
> Subject: Re: Strangeness gadgets.view
>
>
>
> 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 | tmack@mitre.org
>
>
Re: Strangeness gadgets.view
Posted by Ryan Baxter <rb...@gmail.com>.
Yeah that would help, thanks :)
-Ryan
On Jul 20, 2012, at 6:53 AM, Stanton Sievers <ss...@us.ibm.com> wrote:
> Hi Ryan,
>
> I think you meant to link to this JIRA :)
>
> https://issues.apache.org/jira/browse/SHINDIG-1792
>
> -Stanton
>
>
>
> From: Ryan Baxter <rb...@apache.org>
> To: dev@shindig.apache.org,
> Cc: "dev@rave.apache.org" <de...@rave.apache.org>
> Date: 07/20/2012 02:08
> Subject: Re: Strangeness gadgets.view
>
>
>
> 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 | tmack@mitre.org
>
>
Re: Strangeness gadgets.view
Posted by Ryan Baxter <rb...@gmail.com>.
Yeah that would help, thanks :)
-Ryan
On Jul 20, 2012, at 6:53 AM, Stanton Sievers <ss...@us.ibm.com> wrote:
> Hi Ryan,
>
> I think you meant to link to this JIRA :)
>
> https://issues.apache.org/jira/browse/SHINDIG-1792
>
> -Stanton
>
>
>
> From: Ryan Baxter <rb...@apache.org>
> To: dev@shindig.apache.org,
> Cc: "dev@rave.apache.org" <de...@rave.apache.org>
> Date: 07/20/2012 02:08
> Subject: Re: Strangeness gadgets.view
>
>
>
> 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 | tmack@mitre.org
>
>
Re: Strangeness gadgets.view
Posted by Stanton Sievers <ss...@us.ibm.com>.
Hi Ryan,
I think you meant to link to this JIRA :)
https://issues.apache.org/jira/browse/SHINDIG-1792
-Stanton
From: Ryan Baxter <rb...@apache.org>
To: dev@shindig.apache.org,
Cc: "dev@rave.apache.org" <de...@rave.apache.org>
Date: 07/20/2012 02:08
Subject: Re: Strangeness gadgets.view
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 | tmack@mitre.org
Re: Strangeness gadgets.view
Posted by Stanton Sievers <ss...@us.ibm.com>.
Hi Ryan,
I think you meant to link to this JIRA :)
https://issues.apache.org/jira/browse/SHINDIG-1792
-Stanton
From: Ryan Baxter <rb...@apache.org>
To: dev@shindig.apache.org,
Cc: "dev@rave.apache.org" <de...@rave.apache.org>
Date: 07/20/2012 02:08
Subject: Re: Strangeness gadgets.view
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 | tmack@mitre.org
Re: Strangeness gadgets.view
Posted by Ryan Baxter <rb...@apache.org>.
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 | tmack@mitre.org
Re: Strangeness gadgets.view
Posted by Ryan Baxter <rb...@apache.org>.
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 | tmack@mitre.org