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. > >
