Henry, I was actually thinking of having it be it's own file, with it's own guice module. I think this provides the most flexibility to the implementer. I know for our use case it would be simpler for us to just replace a guice module as this administration information is stored separately from the configuration information in our application.
-Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Henry Saputra <[email protected]> To: [email protected], Date: 09/01/2011 03:16 PM Subject: Re: Replacing The Gadget Blacklist Functionality I was actually thinking about moving it to container.js file. Probably we could also include the new admin setup into container file itself? - Henry On Thu, Sep 1, 2011 at 7:20 AM, Ryan J Baxter <[email protected]> wrote: > As I look into how to add more functionality around gadget administration > into Shindig (https://issues.apache.org/jira/browse/SHINDIG-1601) I came > across the gadget blacklist which can be enabled/specified in > shindig.properties. I am wondering what people think about combining that > list into a more general gadget administration store. For the work I am > doing around administrating the features and RPC services a gadget is > allowed to use I have created a sample store in shindig, which is really > just a JSON file. (You can replace this file via a guice module.) Here > is an example... > > { > "default" : { > "http://www.google.com/ig/modules/horoscope.xml"; : ["views", "tabs", > "setprefs", "dynamic-height", "settitle"], > "http://www.labpixies.com/campaigns/todo/todo.xml"; : ["setprefs", > "dynamic-height", "views"] > }, > "foo" : { > "http://example.com/gadget.xml"; : ["tabs"] > } > } > > In essence this JSON file specifies which features each gadget is allowed > to use in a given container. If a gadget requests a feature not in the > array for that container the metadata request will fail for that gadget. > You could also easily provide the same functionality the blacklist > provides based off the information in this store, the store pretty much > acts like a whitelist where the administrator needs to specifically allow > gadget to render in a given container and provide the features that gadget > is allowed to use. Obviously this is the inverse of what the blacklist > did, but I don't think it makes sense to have to maintain two lists. > Thoughts? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > >
