Ryan, Do you have link to the thread about this?
Been trying to search for it but couldnt find it. - Henry On Thu, Jun 30, 2011 at 6:06 PM, Ryan J Baxter <[email protected]> wrote: > I am pretty sure your correct Henry. I know Mark was thinking about > redoing app data and preferences in the OpenSocial 2.0 spec, but I don't > think there was much progress on that. > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: Henry Saputra <[email protected]> > To: [email protected], > Date: 06/29/2011 05:32 PM > Subject: Re: Implementing userPrefs with common container > > > > I think AppData is per person and per gagdet/app id. > So what Craig was saying that the same gadget could be run by > different user and it could ask for the user preference for other > user(s). > > - Henry > > On Wed, Jun 29, 2011 at 10:56 AM, Davies,Douglas <[email protected]> wrote: >> Craig, >> >> Thanks for the info. I thought appdata was per person, not per gadget. >> I'm probably misunderstanding something here. I will investigate. >> >> I'm also trying to find the correct server-side metadata plugin point. >> It looks like the MetadataGadgetContext class might be the right plugin >> point by implementing getUserPrefs(). But I don't see an easy way to do >> this since MetadataGadgetContext is a protected class in >> GadgetsHandlerService and there doesn't seem to be any Guice >> configuration around this module that I can inject something different. >> We build from the maven artifacts, so I don't really want to be >> *patching* any code here. >> >> Thanks, >> doug >> >> -----Original Message----- >> From: Craig McClanahan [mailto:[email protected]] >> Sent: Wednesday, June 29, 2011 1:26 PM >> To: [email protected] >> Subject: Re: Implementing userPrefs with common container >> >> On Wed, Jun 29, 2011 at 7:02 AM, Davies,Douglas <[email protected]> >> wrote: >> >>> I've implemented the set_pref rpc call and it's getting called >>> appropriately from the gadgets. I've got this sitting ontop of >> appdata >>> and it seems to be persisting my values fine. I am using the gadget >> url >>> combined with the preference name to generate the appdata store key. >> I >>> had to search/replace all non appdata friendly key characters >>> (AppHandler only allows alpha-numeric, dash, underscore, and period). >>> Does this sound like the right way to be doing this if I want to >>> leverage off of appdata? >>> >>> One caution on using appdata for this purpose -- all users of the same >> gadget can read the appdata settings for all users, and therefore could >> see >> other users's preference settings in your approach. That is not a good >> idea >> from a privacy perspective. >> >> In our implementation (Jive Software), we created additional RPC calls >> back >> to the server and stored the privacy settings in a database table keyed >> by >> user, gadget, and preference name. We go beyond the spec requirements >> and >> allow a gadget to define a custom view for their preferences, or default >> to >> constructing a generic one based on the data types. >> >> Craig McClanahan >> >>> >>> >>> I am now figuring out where to plugin to retrieve and override the >>> userprefs returned from the metadata/iframe calls. Again... any >>> feedback from anyone who has been through this process is appreciated. >>> >>> >>> >>> doug >>> >>> >>> >>> From: Davies,Douglas >>> Sent: Monday, June 27, 2011 9:59 AM >>> To: '[email protected]' >>> Subject: Implementing userPrefs with common container >>> >>> >>> >>> I'm looking into implementing userPrefs with the common container, but >>> I'm unclear as to what is implemented and what just needs to be >>> extended. >>> >>> >>> >>> My first step is to implement set_pref and register it with rpc. I'm >>> thinking of implementing this using the appData api (as I've seen >> other >>> threads along those lines). I realize appData needs to be extended to >>> use a persistent store. I'm not sure what the default implementation >> is >>> using (in memory?). >>> >>> >>> >>> I would then think I need to modify the server side to return these >>> userPrefs (overriding the ones from the gadget spec). I'm not sure >>> where to plug into here to use my persistent store. It seems like the >>> old container way was for DefaultIframeUriManager to return this when >> it >>> created the iframe url. But I'm not sure that is what common >> container >>> is doing. I think I need to plug into the gadgets.metadata request. >>> >>> >>> >>> Also it appears that sites like iGoogle provide a user interface from >>> within the container to set the user prefs. Is it the containers or >> the >>> gadgets responsibility to do this or a little bit of both? I can see >> a >>> horoscope gadget using userPrefs to store a birthdate but not >>> necessarily have to have a separate settings panel like iGoogle >>> provides. >>> >>> >>> >>> Has anyone been through this process that would be willing to share >> what >>> they did? Is this something that the common container will eventually >>> support out of the box? How far off base am I with my thinking here? >>> >>> >>> >>> Thanks, >>> >>> Doug >>> >>> >> >> > > > >
