You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Kevin Brown (JIRA)" <ji...@apache.org> on 2008/02/19 00:02:34 UTC

[jira] Closed: (SHINDIG-44) Support configuration variable substitution into resource files.

     [ https://issues.apache.org/jira/browse/SHINDIG-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown closed SHINDIG-44.
------------------------------

    Resolution: Fixed

rev628908

> 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 ${@variable} 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.