>-----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
