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: [email protected], 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." <[email protected]> To: "[email protected]" <[email protected]>, Date: 02/21/2012 05:33 PM Subject: RE: User Prefs Panel Brainstorm >-----Original Message----- >From: daviesd [mailto:[email protected]] >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
