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" <rjbax...@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." <mfrank...@mitre.org> > To: "dev@shindig.apache.org" <dev@shindig.apache.org>, > Date: 02/21/2012 05:33 PM > Subject: RE: User Prefs Panel Brainstorm > > > >> >-----Original Message----- >> >From: daviesd [mailto:davi...@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 > > >
