You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by daviesd <da...@oclc.org> on 2012/02/21 22:44:08 UTC
User Prefs Panel Brainstorm
I¹ve started to implement a User Prefs panel. I¹m thinking of implementing
it as a feature. My problem is I¹m flip flopping between it being a
container feature v.s. a gadget feature. There are benefits and drawbacks
to both. I kind of like having it as a gadget feature. It could provide a
default implementation via a view (let¹s call it userprefspanel). If the
user didn¹t want the default then they could just not include the feature,
but still provide the view. This requires the container to know the name of
the view so that it can provide navigation chrome to get there. It also
requires the gadget to do specific things, which is fine for my 1st party
gadgets but not 3rd party. So then I flip back to the container
implementation. It would simply provide a generic implementation and the
chrome implementer would just need to know how to initiate it. I know the
Rave guys have done a bit of this and it seems to be completely container
implemented? Is anyone actively working on the common container and was
there future plans to implement it there? Just looking for some feedback.
Thanks.
doug
RE: User Prefs Panel Brainstorm
Posted by Stanton Sievers <ss...@us.ibm.com>.
I don't think there would be UI contributed as part of the common
container
. I was thinking more along the lines of making sure that the CC provides
appropriate APIs for getting and setting the preferences utilizing the
functions that the CC was configured with. Something like
osapi.container.Container.setPref(name, value) and getPrefs() for example
Then any implementer of the preferences UI would simply utilize those APIs
to reach into the preferences store that was configured. It keeps all of
the data flowing the CC, as it should, since navigateGadget and the
set_prefs rely on it.
I don't see anything like this today in Shindig in the CC implementation.
Please correct me if I'm wrong. :)
Thanks,
-Stanton
From: Ryan J Baxter/Westford/IBM@Lotus
To: dev@shindig.apache.org,
Date: 02/21/2012 20:31
Subject: RE: User Prefs Panel Brainstorm
Actually the view name to use for displaying preferences in a gadget was
defined in the spec in 2.0. See
http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#gadgets.views.ViewType
.
One other thing to think about with a container side implementation would
be the savings you would get from not having to make an RPC request from
the gadget to the container, but that is a pretty small savings. Also if
you have a dedicated view you will need to render the preferences view
each time you want to change a preferences, and then render the view you
were on before. With a container implementation you have one less view to
render.
I am not to fond of putting this implementation in the common container
because I am pretty sure every container will end up overriding it to
match the look and feel of its container, I am not sure how much use it
would actually be.
-Ryan
From: "Franklin, Matthew B." <mf...@mitre.org>
To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
Date: 02/21/2012 05:33 PM
Subject: RE: User Prefs Panel Brainstorm
>-----Original Message-----
>From: daviesd [mailto:daviesd@oclc.org]
>Sent: Tuesday, February 21, 2012 4:44 PM
>To: shindig
>Subject: User Prefs Panel Brainstorm
>
>I¹ve started to implement a User Prefs panel. I¹m thinking of
implementing
>it as a feature. My problem is I¹m flip flopping between it being a
>container feature v.s. a gadget feature. There are benefits and
drawbacks
>to both. I kind of like having it as a gadget feature. It could provide
a
>default implementation via a view (let¹s call it userprefspanel). If the
>user didn¹t want the default then they could just not include the
feature,
>but still provide the view. This requires the container to know the name
of
>the view so that it can provide navigation chrome to get there. It also
>requires the gadget to do specific things, which is fine for my 1st party
>gadgets but not 3rd party. So then I flip back to the container
We (Rave) will support both container and a gadget managed edit
preferences. The most recent release only has container generated forms,
but in 0.9-incubating we should have the ability to define a custom view.
This means that Rave gadget developers will only need to implement a view
with a name something like "edit_prefs" and set the flag when registering
the gadget. We will then test the flag when edit prefs is selected from
the chrome and take appropriate action.
What that view name is we haven't decided. There was some discussion on
the spec list about what it should be ~1 yr ago but I haven't looked.
>implementation. It would simply provide a generic implementation and the
>chrome implementer would just need to know how to initiate it. I know
the
>Rave guys have done a bit of this and it seems to be completely container
>implemented? Is anyone actively working on the common container and was
>there future plans to implement it there? Just looking for some
feedback.
>
>Thanks.
>doug
Re: User Prefs Panel Brainstorm
Posted by daviesd <da...@oclc.org>.
Thanks for all the great feedback. So here¹s what I am thinking...
* I create a new container feature called setprefs-ui (or something like
that) that displays an edit field for each preference just like Rave or
iGoogle does.
* My chrome has a way to select EDIT PREFERENCES. If selected it first
checks if the gadget supports the PREFRENCES view and if so it navigates to
it, otherwise it displays this generic container ui.
I noticed iGoogle and Rave both push down the gadget content to display the
preferences. I¹m thinking of replacing the view area, displaying my ui, and
then when done redisplaying the original view (perhaps hiding/unhiding the
gadget element or renavigating). I¹m sure there are some kinks I haven¹t
noticed that I¹ll discover along the way.
So would a DEFAULT setprefs-ui feature be useful to include back into the
project or is this really something each container implementer should have
to do? If it seems useful I¹ll see about writing this so that it¹s
contributable (after I brush up on my javascript skills <g>).
doug
On 2/21/12 8:30 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
> Actually the view name to use for displaying preferences in a gadget was
> defined in the spec in 2.0. See
> http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#gadg
> ets.views.ViewType
> .
>
> One other thing to think about with a container side implementation would
> be the savings you would get from not having to make an RPC request from
> the gadget to the container, but that is a pretty small savings. Also if
> you have a dedicated view you will need to render the preferences view
> each time you want to change a preferences, and then render the view you
> were on before. With a container implementation you have one less view to
> render.
>
> I am not to fond of putting this implementation in the common container
> because I am pretty sure every container will end up overriding it to
> match the look and feel of its container, I am not sure how much use it
> would actually be.
>
> -Ryan
>
>
>
>
> From: "Franklin, Matthew B." <mf...@mitre.org>
> To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
> Date: 02/21/2012 05:33 PM
> Subject: RE: User Prefs Panel Brainstorm
>
>
>
>> >-----Original Message-----
>> >From: daviesd [mailto:daviesd@oclc.org]
>> >Sent: Tuesday, February 21, 2012 4:44 PM
>> >To: shindig
>> >Subject: User Prefs Panel Brainstorm
>> >
>> >I¹ve started to implement a User Prefs panel. I¹m thinking of
> implementing
>> >it as a feature. My problem is I¹m flip flopping between it being a
>> >container feature v.s. a gadget feature. There are benefits and
> drawbacks
>> >to both. I kind of like having it as a gadget feature. It could provide
> a
>> >default implementation via a view (let¹s call it userprefspanel). If the
>> >user didn¹t want the default then they could just not include the
> feature,
>> >but still provide the view. This requires the container to know the name
> of
>> >the view so that it can provide navigation chrome to get there. It also
>> >requires the gadget to do specific things, which is fine for my 1st party
>> >gadgets but not 3rd party. So then I flip back to the container
>
> We (Rave) will support both container and a gadget managed edit
> preferences. The most recent release only has container generated forms,
> but in 0.9-incubating we should have the ability to define a custom view.
> This means that Rave gadget developers will only need to implement a view
> with a name something like "edit_prefs" and set the flag when registering
> the gadget. We will then test the flag when edit prefs is selected from
> the chrome and take appropriate action.
>
> What that view name is we haven't decided. There was some discussion on
> the spec list about what it should be ~1 yr ago but I haven't looked.
>
>> >implementation. It would simply provide a generic implementation and the
>> >chrome implementer would just need to know how to initiate it. I know
> the
>> >Rave guys have done a bit of this and it seems to be completely container
>> >implemented? Is anyone actively working on the common container and was
>> >there future plans to implement it there? Just looking for some
> feedback.
>> >
>> >Thanks.
>> >doug
>
>
>
Re: User Prefs Panel Brainstorm
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 2/21/12 8:30 PM, "Ryan J Baxter" <rj...@us.ibm.com> wrote:
>Actually the view name to use for displaying preferences in a gadget was
>defined in the spec in 2.0. See
>http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#
>gadgets.views.ViewType
Thanks Ryan. Even better than a discussion :)
>.
>
>One other thing to think about with a container side implementation would
>be the savings you would get from not having to make an RPC request from
>the gadget to the container, but that is a pretty small savings. Also if
>you have a dedicated view you will need to render the preferences view
>each time you want to change a preferences, and then render the view you
>were on before. With a container implementation you have one less view
>to
>render.
>
>I am not to fond of putting this implementation in the common container
>because I am pretty sure every container will end up overriding it to
>match the look and feel of its container, I am not sure how much use it
>would actually be.
+1
>
>-Ryan
>
>
>
>
>From: "Franklin, Matthew B." <mf...@mitre.org>
>To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
>Date: 02/21/2012 05:33 PM
>Subject: RE: User Prefs Panel Brainstorm
>
>
>
>>-----Original Message-----
>>From: daviesd [mailto:daviesd@oclc.org]
>>Sent: Tuesday, February 21, 2012 4:44 PM
>>To: shindig
>>Subject: User Prefs Panel Brainstorm
>>
>>I¹ve started to implement a User Prefs panel. I¹m thinking of
>implementing
>>it as a feature. My problem is I¹m flip flopping between it being a
>>container feature v.s. a gadget feature. There are benefits and
>drawbacks
>>to both. I kind of like having it as a gadget feature. It could
>>provide
>a
>>default implementation via a view (let¹s call it userprefspanel). If the
>>user didn¹t want the default then they could just not include the
>feature,
>>but still provide the view. This requires the container to know the
>>name
>of
>>the view so that it can provide navigation chrome to get there. It also
>>requires the gadget to do specific things, which is fine for my 1st party
>>gadgets but not 3rd party. So then I flip back to the container
>
>We (Rave) will support both container and a gadget managed edit
>preferences. The most recent release only has container generated forms,
>but in 0.9-incubating we should have the ability to define a custom view.
>This means that Rave gadget developers will only need to implement a view
>with a name something like "edit_prefs" and set the flag when registering
>the gadget. We will then test the flag when edit prefs is selected from
>the chrome and take appropriate action.
>
>What that view name is we haven't decided. There was some discussion on
>the spec list about what it should be ~1 yr ago but I haven't looked.
>
>>implementation. It would simply provide a generic implementation and the
>>chrome implementer would just need to know how to initiate it. I know
>the
>>Rave guys have done a bit of this and it seems to be completely container
>>implemented? Is anyone actively working on the common container and was
>>there future plans to implement it there? Just looking for some
>feedback.
>>
>>Thanks.
>>doug
>
>
RE: User Prefs Panel Brainstorm
Posted by Ryan J Baxter <rj...@us.ibm.com>.
Actually the view name to use for displaying preferences in a gadget was
defined in the spec in 2.0. See
http://opensocial-resources.googlecode.com/svn/spec/2.0.1/Core-Gadget.xml#gadgets.views.ViewType
.
One other thing to think about with a container side implementation would
be the savings you would get from not having to make an RPC request from
the gadget to the container, but that is a pretty small savings. Also if
you have a dedicated view you will need to render the preferences view
each time you want to change a preferences, and then render the view you
were on before. With a container implementation you have one less view to
render.
I am not to fond of putting this implementation in the common container
because I am pretty sure every container will end up overriding it to
match the look and feel of its container, I am not sure how much use it
would actually be.
-Ryan
From: "Franklin, Matthew B." <mf...@mitre.org>
To: "dev@shindig.apache.org" <de...@shindig.apache.org>,
Date: 02/21/2012 05:33 PM
Subject: RE: User Prefs Panel Brainstorm
>-----Original Message-----
>From: daviesd [mailto:daviesd@oclc.org]
>Sent: Tuesday, February 21, 2012 4:44 PM
>To: shindig
>Subject: User Prefs Panel Brainstorm
>
>I¹ve started to implement a User Prefs panel. I¹m thinking of
implementing
>it as a feature. My problem is I¹m flip flopping between it being a
>container feature v.s. a gadget feature. There are benefits and
drawbacks
>to both. I kind of like having it as a gadget feature. It could provide
a
>default implementation via a view (let¹s call it userprefspanel). If the
>user didn¹t want the default then they could just not include the
feature,
>but still provide the view. This requires the container to know the name
of
>the view so that it can provide navigation chrome to get there. It also
>requires the gadget to do specific things, which is fine for my 1st party
>gadgets but not 3rd party. So then I flip back to the container
We (Rave) will support both container and a gadget managed edit
preferences. The most recent release only has container generated forms,
but in 0.9-incubating we should have the ability to define a custom view.
This means that Rave gadget developers will only need to implement a view
with a name something like "edit_prefs" and set the flag when registering
the gadget. We will then test the flag when edit prefs is selected from
the chrome and take appropriate action.
What that view name is we haven't decided. There was some discussion on
the spec list about what it should be ~1 yr ago but I haven't looked.
>implementation. It would simply provide a generic implementation and the
>chrome implementer would just need to know how to initiate it. I know
the
>Rave guys have done a bit of this and it seems to be completely container
>implemented? Is anyone actively working on the common container and was
>there future plans to implement it there? Just looking for some
feedback.
>
>Thanks.
>doug
RE: User Prefs Panel Brainstorm
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: daviesd [mailto:daviesd@oclc.org]
>Sent: Tuesday, February 21, 2012 4:44 PM
>To: shindig
>Subject: User Prefs Panel Brainstorm
>
>I¹ve started to implement a User Prefs panel. I¹m thinking of implementing
>it as a feature. My problem is I¹m flip flopping between it being a
>container feature v.s. a gadget feature. There are benefits and drawbacks
>to both. I kind of like having it as a gadget feature. It could provide a
>default implementation via a view (let¹s call it userprefspanel). If the
>user didn¹t want the default then they could just not include the feature,
>but still provide the view. This requires the container to know the name of
>the view so that it can provide navigation chrome to get there. It also
>requires the gadget to do specific things, which is fine for my 1st party
>gadgets but not 3rd party. So then I flip back to the container
We (Rave) will support both container and a gadget managed edit preferences. The most recent release only has container generated forms, but in 0.9-incubating we should have the ability to define a custom view. This means that Rave gadget developers will only need to implement a view with a name something like "edit_prefs" and set the flag when registering the gadget. We will then test the flag when edit prefs is selected from the chrome and take appropriate action.
What that view name is we haven't decided. There was some discussion on the spec list about what it should be ~1 yr ago but I haven't looked.
>implementation. It would simply provide a generic implementation and the
>chrome implementer would just need to know how to initiate it. I know the
>Rave guys have done a bit of this and it seems to be completely container
>implemented? Is anyone actively working on the common container and was
>there future plans to implement it there? Just looking for some feedback.
>
>Thanks.
>doug
Re: User Prefs Panel Brainstorm
Posted by Stanton Sievers <ss...@us.ibm.com>.
Hi Doug,
First, I don't know of anyone actively working on this.
Second, I think the container feature approach would be best for a couple
reasons. It doesn't mandate that the gadgets do anything, as you
mentioned. It also helps to keep the look and feel the same across the
entire page if the container manages that UI. Having this container side
also gives you the ability to easily integrate with the GET_PREFERENCES
and SET_PREFERENCES functions that can be provided in the
osapi.container.ContainerConfig. Those functions could back the UI.
-Stanton
From: daviesd <da...@oclc.org>
To: shindig <de...@shindig.apache.org>,
Date: 02/21/2012 16:49
Subject: User Prefs Panel Brainstorm
I¹ve started to implement a User Prefs panel. I¹m thinking of
implementing
it as a feature. My problem is I¹m flip flopping between it being a
container feature v.s. a gadget feature. There are benefits and drawbacks
to both. I kind of like having it as a gadget feature. It could provide
a
default implementation via a view (let¹s call it userprefspanel). If the
user didn¹t want the default then they could just not include the feature,
but still provide the view. This requires the container to know the name
of
the view so that it can provide navigation chrome to get there. It also
requires the gadget to do specific things, which is fine for my 1st party
gadgets but not 3rd party. So then I flip back to the container
implementation. It would simply provide a generic implementation and the
chrome implementer would just need to know how to initiate it. I know the
Rave guys have done a bit of this and it seems to be completely container
implemented? Is anyone actively working on the common container and was
there future plans to implement it there? Just looking for some feedback.
Thanks.
doug
Re: User Prefs Panel Brainstorm
Posted by Evgeny Bogdanov <ev...@epfl.ch>.
I would vote for a gadget feature backed-up with appdata.
The main reason is the use of a gadget outside a container.
For example, a secret url is given to the user:
http://localhost:8080/gadgets/ifr?url=http://iamac71.epfl.ch/iframe.xml&st=secure_token
Then the user can open this url with a browser,
Since there is no container wrapping this gadget, user prefs are just lost,
the feature with appdata would solve this problem.
The second reason is the additional implementation on container side.
1. Currently I have to create a table in db for user prefs, set api and
add/change JS-code from shindig to the container
to work with userprefs.
2. With a gadget feature based on appdata, I don't need to do it. I just
plug shindig as a base
for gadgets and it works. It makes it a lot easier to add gadgets to
different environments.
The obvious disadvantage is that container can't control the visual
representation of prefs panel.
IMO, the advantages are better.
Evgeny
PS: I saw on the OS-list that appdata will be a required api (if it's
not already)
On 21.02.12 22:44, daviesd wrote:
> I¹ve started to implement a User Prefs panel. I¹m thinking of implementing
> it as a feature. My problem is I¹m flip flopping between it being a
> container feature v.s. a gadget feature. There are benefits and drawbacks
> to both. I kind of like having it as a gadget feature. It could provide a
> default implementation via a view (let¹s call it userprefspanel). If the
> user didn¹t want the default then they could just not include the feature,
> but still provide the view. This requires the container to know the name of
> the view so that it can provide navigation chrome to get there. It also
> requires the gadget to do specific things, which is fine for my 1st party
> gadgets but not 3rd party. So then I flip back to the container
> implementation. It would simply provide a generic implementation and the
> chrome implementer would just need to know how to initiate it. I know the
> Rave guys have done a bit of this and it seems to be completely container
> implemented? Is anyone actively working on the common container and was
> there future plans to implement it there? Just looking for some feedback.
>
> Thanks.
> doug
>
Re: User Prefs Panel Brainstorm
Posted by Mark Weitzel <we...@gmail.com>.
A couple of thoughts...
In opensocial 2.0 there is a view defined called preferences. I think
adding a new gadget feature that provided a default implementation of this
would be interesting. The way that this could work is that the feature
provides hooks into the gadget menu via the action contributions. The
implementation could look for a view called preferences in the gadget. If
it's not there it could then use its default one.
One other thing that would be interesting is if you implemented this using
opensocial templates. This way you could have some flexibility in teeming
it etc.
What do you think?
Mark w.
On Feb 21, 2012 4:44 PM, "daviesd" <da...@oclc.org> wrote:
> I¹ve started to implement a User Prefs panel. I¹m thinking of implementing
> it as a feature. My problem is I¹m flip flopping between it being a
> container feature v.s. a gadget feature. There are benefits and drawbacks
> to both. I kind of like having it as a gadget feature. It could provide a
> default implementation via a view (let¹s call it userprefspanel). If the
> user didn¹t want the default then they could just not include the feature,
> but still provide the view. This requires the container to know the name
> of
> the view so that it can provide navigation chrome to get there. It also
> requires the gadget to do specific things, which is fine for my 1st party
> gadgets but not 3rd party. So then I flip back to the container
> implementation. It would simply provide a generic implementation and the
> chrome implementer would just need to know how to initiate it. I know the
> Rave guys have done a bit of this and it seems to be completely container
> implemented? Is anyone actively working on the common container and was
> there future plans to implement it there? Just looking for some feedback.
>
> Thanks.
> doug
>