Proposal: checking view type

[yoichiro]

Hi folks,

In some containers based on apache shindig, the result of the
gadgets.views.View#getName() function is not equal to the constant
value defined by gadgets.views.ViewType class. In particular, the
result of the gadgets.views.View#getName() on the canvas view is
"canvas" written in the config/container.js file, and the constant
value of ViewType.CANVAS is defined as "CANVAS" in the features/views/
views.js file.

Therefore, in current version of opensocial, we cannot confirm which
view type is this view using getName() function. But, fortunately, it
will be able to ensure that "CANVAS" and "canvas" is same, because
each view can have some aliases.

My proposal is to add the following function for checking view type.

/**
* Returns whether this view is specified ViewType.
* @param {gadgets.views.ViewType | String} ViewType object or view
name.
* @return {Boolean} True if this is specified ViewType.
*/
gadgets.views.View.prototype.checkType = function(viewType) {...};

The usage I'm thinking is the following code:

var view = gadgets.views.getCurrentView();
var name = view.getName(); // => "canvas"
name == gadgets.views.ViewType.CANVAS; // => false
view.checkType(gadgets.views.ViewType.CANVAS); // => true

Thanks,
Yoichiro

[Kevin Brown]

This comes back to a fundamental problem with views -- "type" is largely meaningless. There was some attempt at doing semantically meaningful attribute addition (http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gadgets-reference08#gadgets.views.View.isOnlyVisibleGadget), but we never continued with that.

There will likely always be an arbitrary number of different views for different containers. There are already many different container types deployed (or close to being deployed with support announced).

Consider all the types of places where you might want to run an opensocial app:

- Online social networks in the myspace / facebook / orkut mold (most closely matches current enum values)
- Personalized sites like my yahoo, pageflakes, or igoogle
- Blogs (six apart and blogger are both containers, and google's friend connect puts opensocial into even more)
- Desktop environments
- Mobile

I think the enumeration is far too rigid for this.

I'm a strong proponent of capability based systems for these purposes. Currently, developers are simply using the view name that makes sense on the container their app is running in (and writing different apps for different containers). If we want to improve portability, perhaps we could have attributes on the content elements themselves?

[yoichiro]

Thank you for your reply and I'm sorry about my reply too late.

I understand the point that it is difficult to define ViewType because
there are a variety of runtime environments. I think, however, common
ViewType Enum is very important for the portability of the OpenSocial
application. Well, if there is no common ViewType, a developer must
always have the mapping table with Domain and View in the application.

OpenSocial is the common and standard specification for the social
platform. I think that the enhancement of View Type Enum is proof of
the evolution of OpenSocial Platform. Therefore, the View class is
able to define the function based on ViewType Enum, I think. Of
course, the name of View is also generally used, but I seem ViewType
Enum is more important. This Enum is necessary to develop easily.

Is my idea incorrect?

Best regards,
Yoichiro

On Oct 10, 3:11 am, "Kevin Brown" <e...@google.com> wrote:
> This comes back to a fundamental problem with views -- "type" is largely
> meaningless. There was some attempt at doing semantically meaningful

> attribute addition (http://www.opensocial.org/Technical-Resources/opensocial-spec-v08/gad...),

> but we never continued with that.
>
> There will likely always be an arbitrary number of different views for
> different containers. There are already many different container types
> deployed (or close to being deployed with support announced).
>
> Consider all the types of places where you might want to run an opensocial
> app:
>
> - Online social networks in the myspace / facebook / orkut mold (most
> closely matches current enum values)
> - Personalized sites like my yahoo, pageflakes, or igoogle
> - Blogs (six apart and blogger are both containers, and google's friend
> connect puts opensocial into even more)
> - Desktop environments
> - Mobile
>
> I think the enumeration is far too rigid for this.
>
> I'm a strong proponent of capability based systems for these purposes.
> Currently, developers are simply using the view name that makes sense on the
> container their app is running in (and writing different apps for different
> containers). If we want to improve portability, perhaps we could have
> attributes on the content elements themselves?
>

[Kevin Brown]

On Thu, Oct 16, 2008 at 6:29 PM, yoichiro <yoic...@eisbahn.jp> wrote:

Thank you for your reply and I'm sorry about my reply too late.

I understand the point that it is difficult to define ViewType because
there are a variety of runtime environments. I think, however, common
ViewType Enum is very important for the portability of the OpenSocial
application. Well, if there is no common ViewType, a developer must
always have the mapping table with Domain and View in the application.

OpenSocial is the common and standard specification for the social
platform. I think that the enhancement of View Type Enum is proof of
the evolution of OpenSocial Platform. Therefore, the View class is
able to define the function based on ViewType Enum, I think. Of
course, the name of View is also generally used, but I seem ViewType
Enum is more important. This Enum is necessary to develop easily.

Portability still exists, it's just convention based rather than embedded in the standard. "profile" and "canvas" pretty much always mean the same thing no matter what container you're using.