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/01/20 10:18:35 UTC

[jira] Created: (SHINDIG-22) Unify js library configuration model

Unify js library configuration model
------------------------------------

                 Key: SHINDIG-22
                 URL: https://issues.apache.org/jira/browse/SHINDIG-22
             Project: Shindig
          Issue Type: Improvement
            Reporter: Kevin Brown
            Assignee: Kevin Brown


Introduce a unified configuration model for all JsLibrary features to avoid inline scripts being used for configuration. This improves type=url support, reduces errors, and minimizes the number of changes required by integrators who need to roll up their systems.

My proposal is to add a config namespace to gadgets.*, which is not part of the gadgets spec, but can be safely depended on by anyone writing features for the shindig platform (using the feature.xml mechanism). A rough API spec:

/**
 * Registers a configurable component and its configuration parameters.
 *
 * @param {string} component The name of the component to register. Should be the same as the fully qualified name of the <Require> feature or the fully qualified javascript object reference (e.g. gadgets.io).
 * @param {object} config Mapping of option name to validation function that takes the form function(data) {return valid(data) ? true : false;}
 * @param {function} opt_callbackA function to be invoked when a configuration is registered. If passed, this function will be invoked immediately after a call to init has been made. Do not assume that dependent libraries have been configured until after init is complete. If you rely on this, it is better to defer calling dependent libraries until you can be sure that configuration is complete. Takes the form function(errors, extra), where errors will be an array of parameters that failed to validate, and extra will be any parameters that were specified that you did not explicitly register up front.
 */
gadgets.config.register = function(component, config, opt_callback);

/**
 * Used when a configuration needs to be fetched for a component that did not register a callback. Useful when inspecting the config parameters of another component.
 *
 * @param {string} component @see gadgets.config.register
 * @return {object} The component's config parameters
 * @throws {Error} When requesting a component that was not registered.
 */
gadgets.config.get = function(component);

/**
 * @param {object} config. All feature configuration, in the form:
 * <code>
 *   {"component": {property: "value"}};
 * </code>
 **/
gadgets.config.init = function(config);

We should also provide a list of common validation routines (regular expression based, enumeration based, etc.). For example:

gadgets.config.enumValidator = function(list) {
  return function(data) {
    for (var i = 0, test; test = list[i]; ++i) {
      if (data === list[i]) {
        return true;
      }
    }
    return false;
  }
}

gadgets.config.regexValidator = function(re) {
  return function(data) {
    return re.test(data);
  }
}

To make all of this work correctly:

- gadgets.config *must* be the first library included in core (easily handled by JsFeatureLoader, which guarantees the order of includes)
- gadgets.config.init *must* be called after all features have been fully loaded and have registered their configuration
- gadgets.config.init *must* be called before any feature-dependent code is called, such as gadget rendering code.
- features that use gadgets.config *must not* execute any code via up front initialization that depends on config being registered, and should instead provide init callbacks and / or provide lazy configuration retrieval mechanisms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (SHINDIG-22) Unify js library configuration model

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown closed SHINDIG-22.
------------------------------

    Resolution: Fixed

rev628908 addresses this.

> Unify js library configuration model
> ------------------------------------
>
>                 Key: SHINDIG-22
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-22
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Features, Gadgets Server - Java, Javascript
>            Reporter: Kevin Brown
>            Assignee: Kevin Brown
>
> Introduce a unified configuration model for all JsLibrary features to avoid inline scripts being used for configuration. This improves type=url support, reduces errors, and minimizes the number of changes required by integrators who need to roll up their systems.
> My proposal is to add a config namespace to gadgets.*, which is not part of the gadgets spec, but can be safely depended on by anyone writing features for the shindig platform (using the feature.xml mechanism). A rough API spec:
> /**
>  * Registers a configurable component and its configuration parameters.
>  *
>  * @param {string} component The name of the component to register. Should be the same as the fully qualified name of the <Require> feature or the fully qualified javascript object reference (e.g. gadgets.io).
>  * @param {object} config Mapping of option name to validation function that takes the form function(data) {return valid(data) ? true : false;}
>  * @param {function} opt_callbackA function to be invoked when a configuration is registered. If passed, this function will be invoked immediately after a call to init has been made. Do not assume that dependent libraries have been configured until after init is complete. If you rely on this, it is better to defer calling dependent libraries until you can be sure that configuration is complete. Takes the form function(errors, extra), where errors will be an array of parameters that failed to validate, and extra will be any parameters that were specified that you did not explicitly register up front.
>  */
> gadgets.config.register = function(component, config, opt_callback);
> /**
>  * Used when a configuration needs to be fetched for a component that did not register a callback. Useful when inspecting the config parameters of another component.
>  *
>  * @param {string} component @see gadgets.config.register
>  * @return {object} The component's config parameters
>  * @throws {Error} When requesting a component that was not registered.
>  */
> gadgets.config.get = function(component);
> /**
>  * @param {object} config. All feature configuration, in the form:
>  * <code>
>  *   {"component": {property: "value"}};
>  * </code>
>  **/
> gadgets.config.init = function(config);
> We should also provide a list of common validation routines (regular expression based, enumeration based, etc.). For example:
> gadgets.config.enumValidator = function(list) {
>   return function(data) {
>     for (var i = 0, test; test = list[i]; ++i) {
>       if (data === list[i]) {
>         return true;
>       }
>     }
>     return false;
>   }
> }
> gadgets.config.regexValidator = function(re) {
>   return function(data) {
>     return re.test(data);
>   }
> }
> To make all of this work correctly:
> - gadgets.config *must* be the first library included in core (easily handled by JsFeatureLoader, which guarantees the order of includes)
> - gadgets.config.init *must* be called after all features have been fully loaded and have registered their configuration
> - gadgets.config.init *must* be called before any feature-dependent code is called, such as gadget rendering code.
> - features that use gadgets.config *must not* execute any code via up front initialization that depends on config being registered, and should instead provide init callbacks and / or provide lazy configuration retrieval mechanisms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (SHINDIG-22) Unify js library configuration model

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown updated SHINDIG-22:
-------------------------------

    Component/s: Javascript
                 Gadgets Server - Java
                 Features

> Unify js library configuration model
> ------------------------------------
>
>                 Key: SHINDIG-22
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-22
>             Project: Shindig
>          Issue Type: Improvement
>          Components: Features, Gadgets Server - Java, Javascript
>            Reporter: Kevin Brown
>            Assignee: Kevin Brown
>
> Introduce a unified configuration model for all JsLibrary features to avoid inline scripts being used for configuration. This improves type=url support, reduces errors, and minimizes the number of changes required by integrators who need to roll up their systems.
> My proposal is to add a config namespace to gadgets.*, which is not part of the gadgets spec, but can be safely depended on by anyone writing features for the shindig platform (using the feature.xml mechanism). A rough API spec:
> /**
>  * Registers a configurable component and its configuration parameters.
>  *
>  * @param {string} component The name of the component to register. Should be the same as the fully qualified name of the <Require> feature or the fully qualified javascript object reference (e.g. gadgets.io).
>  * @param {object} config Mapping of option name to validation function that takes the form function(data) {return valid(data) ? true : false;}
>  * @param {function} opt_callbackA function to be invoked when a configuration is registered. If passed, this function will be invoked immediately after a call to init has been made. Do not assume that dependent libraries have been configured until after init is complete. If you rely on this, it is better to defer calling dependent libraries until you can be sure that configuration is complete. Takes the form function(errors, extra), where errors will be an array of parameters that failed to validate, and extra will be any parameters that were specified that you did not explicitly register up front.
>  */
> gadgets.config.register = function(component, config, opt_callback);
> /**
>  * Used when a configuration needs to be fetched for a component that did not register a callback. Useful when inspecting the config parameters of another component.
>  *
>  * @param {string} component @see gadgets.config.register
>  * @return {object} The component's config parameters
>  * @throws {Error} When requesting a component that was not registered.
>  */
> gadgets.config.get = function(component);
> /**
>  * @param {object} config. All feature configuration, in the form:
>  * <code>
>  *   {"component": {property: "value"}};
>  * </code>
>  **/
> gadgets.config.init = function(config);
> We should also provide a list of common validation routines (regular expression based, enumeration based, etc.). For example:
> gadgets.config.enumValidator = function(list) {
>   return function(data) {
>     for (var i = 0, test; test = list[i]; ++i) {
>       if (data === list[i]) {
>         return true;
>       }
>     }
>     return false;
>   }
> }
> gadgets.config.regexValidator = function(re) {
>   return function(data) {
>     return re.test(data);
>   }
> }
> To make all of this work correctly:
> - gadgets.config *must* be the first library included in core (easily handled by JsFeatureLoader, which guarantees the order of includes)
> - gadgets.config.init *must* be called after all features have been fully loaded and have registered their configuration
> - gadgets.config.init *must* be called before any feature-dependent code is called, such as gadget rendering code.
> - features that use gadgets.config *must not* execute any code via up front initialization that depends on config being registered, and should instead provide init callbacks and / or provide lazy configuration retrieval mechanisms.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.