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 <[email protected]> To: shindig <[email protected]>, 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
