Possibly could have configuration file URLs and passed in as a parameter to the gadget IFRAME?
There would probably need to be a whitelist of URLs, so we could have this be a syndicator -> URL map to make the URLs less cumbersome. Also I've found it incredibly useful in debugging mode to be able to set JS configuration parameters (even on a hosted Shindig server) - possibly there could be URL overrides of parameters as well. Evan On Fri, Feb 1, 2008 at 10:07 AM, Cassie <[EMAIL PROTECTED]> wrote: > I don't think this will work very nicely with people who don't want to > host > shindig themselves. Google's hosted shindig would be pretty worthless if > you > couldn't configure any of the js params... > > We also need to reconcile this with how opensocial works. In the > opensocial > land a new container implements one file, container.js. We need to provide > some way for people to get this file into the iframe easily with shindig. > > I think what some people do right now is wrap a call to a hosted shindig > and > inject their own code inside the iframe. (there are other solutions out > there too). It seems like there should be a better way. > > - Cassie > > > On Fri, Feb 1, 2008 at 2:17 AM, Kevin Brown (JIRA) <[EMAIL PROTECTED]> > wrote: > > > Support configuration variable substitution into resource files. > > ---------------------------------------------------------------- > > > > Key: SHINDIG-44 > > URL: https://issues.apache.org/jira/browse/SHINDIG-44 > > Project: Shindig > > Issue Type: New Feature > > Components: Features, Gadgets Server - Java, Gadgets Server - > PHP > > Reporter: Kevin Brown > > Assignee: Kevin Brown > > Priority: Minor > > > > > > Configuration is currently a major pain point for Shindig, especially > > since we frequently need configuration values passed down to javascript > > libraries. > > > > The solution I'm proposing is very simple: > > > > When shindig starts, load a configuration file containing key value > pairs. > > (implementation dependent) > > Whenever a file that might need configuration is read into memory, > > substitute these variables into the data. > > > > Example: > > > > features/core/feature.xml has a block like this currently: > > > > gadgets.io.init(proxyUrl: '/proxy?'); > > > > To use this, you have to modify the file every time you sync against svn > > just because you use a different path. That sucks. Instead, how about > this? > > > > gadgets.io.init(proxyUrl:'${io.proxyUrl}', jsonProxyUrl: '${ > > io.jsonProxyUrl}'); > > > > and a config file: > > io.proxyUrl = '/proxy?' > > io.jsonProxyUrl = '/proxy?js=1&' > > > > The [EMAIL PROTECTED] syntax should result in a parse error in all syntaxes > > that we care about, although it could conflict with open social's > activity > > stream templates so that might not be ideal. > > > > I think this should only be applicable inside of files loaded through > > JsFeatureLoader -- ideally, only feature.xml files and the javascript > that > > they reference should be affected, but we could potentially expand this > idea > > to other file types if it makes sense to do so. > > > > This proposal could serve as a full replacement for SHINDIG-22, or both > > could be used for situations where you need to calculate or validate at > run > > time. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > >
