On 2/21/12 8:30 PM, "Ryan J Baxter" <[email protected]> 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." <[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 > >
