sanity check w/r appData

[Gregg Horan <gr...@dealer.com>]

I'm trying to implement some gadget configuration persistence  
mechanism in our container, and I ~think~ I see how appData works, but  
wanted to get a sanity check.  I was confused where the appId came  
from, but from the samplecontainer, it looks like it's not a server  
generated ID - but UI drive from the samplecontainer.js/ 
generateSecureToken.

My goal is to support different settings for the same gadget that  
appears in multiple containers (or multiple times in the same  
container).  From what I can tell, it looks like as long as I can  
develop a hash/ID on the client side/js to make such a distinction,  
then I'm all set with the appData by feeding it my own ID.   This  
would be outside the gadget (in the container), thus may not be  
supported if I deploy my gadgets to iGoogle - for example - depending  
on their implementation.

I'd appreciate any feedback if I've interpreted that correctly - or if  
there's something I'm missing.

Thanks.
Gregg
  

Re: sanity check w/r appData

[Gregg Horan <gr...@dealer.com>]

I was thinking that originally, but from the AppDataService interface,  
it doesn't look like that would allow me to save different AppData for  
that gadget if it appeared twice on a page, for example.  The security  
token has a number of extra fields - but none seem like they would  
provide this distinction either.

On Aug 3, 2010, at 10:47 AM, Mat Mannion wrote:

> I believe (though I may be wrong) that it is safe to just use the URL
> of the gadget as the App ID. At least, that's what Java Shindig passes
> through to the AppDataService.
>
> Regards,
>
> Mat
>
> On 3 August 2010 15:13, Gregg Horan <gr...@dealer.com> wrote:
>> I'm trying to implement some gadget configuration persistence  
>> mechanism in
>> our container, and I ~think~ I see how appData works, but wanted to  
>> get a
>> sanity check.  I was confused where the appId came from, but from the
>> samplecontainer, it looks like it's not a server generated ID - but  
>> UI drive
>> from the samplecontainer.js/generateSecureToken.
>>
>> My goal is to support different settings for the same gadget that  
>> appears in
>> multiple containers (or multiple times in the same container).   
>> From what I
>> can tell, it looks like as long as I can develop a hash/ID on the  
>> client
>> side/js to make such a distinction, then I'm all set with the  
>> appData by
>> feeding it my own ID.   This would be outside the gadget (in the  
>> container),
>> thus may not be supported if I deploy my gadgets to iGoogle - for  
>> example -
>> depending on their implementation.
>>
>> I'd appreciate any feedback if I've interpreted that correctly - or  
>> if
>> there's something I'm missing.
>>
>> Thanks.
>> Gregg
>>
>
>
>
> -- 
> Mat Mannion
> Web Developer
> IT Services
> University of Warwick
> Coventry
> CV4 7AL
>
> Tel: 024 765 74433
> Email: M.Mannion@warwick.ac.uk

Re: sanity check w/r appData

[Mat Mannion <M....@warwick.ac.uk>]

I believe (though I may be wrong) that it is safe to just use the URL
of the gadget as the App ID. At least, that's what Java Shindig passes
through to the AppDataService.

Regards,

Mat

On 3 August 2010 15:13, Gregg Horan <gr...@dealer.com> wrote:
> I'm trying to implement some gadget configuration persistence mechanism in
> our container, and I ~think~ I see how appData works, but wanted to get a
> sanity check.  I was confused where the appId came from, but from the
> samplecontainer, it looks like it's not a server generated ID - but UI drive
> from the samplecontainer.js/generateSecureToken.
>
> My goal is to support different settings for the same gadget that appears in
> multiple containers (or multiple times in the same container).  From what I
> can tell, it looks like as long as I can develop a hash/ID on the client
> side/js to make such a distinction, then I'm all set with the appData by
> feeding it my own ID.   This would be outside the gadget (in the container),
> thus may not be supported if I deploy my gadgets to iGoogle - for example -
> depending on their implementation.
>
> I'd appreciate any feedback if I've interpreted that correctly - or if
> there's something I'm missing.
>
> Thanks.
> Gregg
>



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk

UserPref persistence via appData

[Gregg Horan <gr...@dealer.com>]

Thought I might be able to kill 2 birds with one stone when I  
implement the appData backend if I could implement the  
shindig.Container.prototype.userPrefStore as an appData passthrough.   
Append a prefix to the appId so the persistent data can be  
differentiated (between real appData and userpref data for the same  
appId).

If you'll forgive the (lack of) accuracy of the js...  has anyone  
tried anything like this?

shindig.AppDataBasedUserPrefStore.prototype.getPrefs = function 
(gadget) {
     return osapi.appdata.get({
           appId: "UP_" + gadget.id,
           userId: "@me",
           fields: "@all" });
};

shindig.AppDataBasedUserPrefStore.prototype.savePrefs = function 
(gadget) {
     osapi.appdata.update({
           appId: "UP_" + gadget.id,
           userId: "@me",
           data: gadget.UserPrefs });
};

shindig.AppDataBasedUserPrefStore = function() {
   gadgets.UserPrefStore.call(this);
};

shindig.AppDataBasedUserPrefStore.inherits(shindig.UserPrefStore);

shindig.Container.prototype.userPrefStore = new  
shindig.AppDataBasedUserPrefStore();