Looks good, +1 for commit a first implementation t see it in action :)

On Sun, Aug 24, 2008 at 6:54 PM, Vincent Massol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here's a proposal for implementing configuration in the new
> architecture, using components.
> Note: I think this is compatible with Sergiu's proposal here: 
> http://tinyurl.com/6md5jd
>
> General requirements
> =================
>
> * Each module/component can define its own configuration
> * Accessing configuration parameters from Java should be strongly
> typed (ie. getLinkLabelFormat() for getting the link label and not
> getParameter("linklabelformat"))
> * It should be possible to load Configuration data from different
> sources (properties file, xml files, database, xwiki documents, etc)
> * Configuration sources should have an order
> * Any module/component should be able to get the configuration for
> other module/component but in read only mode
> * It should be possible to dynamically add a new configuration source
> at runtime
> * Configuration data should be loaded and cached
>
> Proposed Implementation
> ====================
>
> * Each module/component defines its configuration in a component which
> is a java beans. For example let's take the rendering module. We would
> have a RenderingConfiguration component as in:
>
> public interface RenderingConfiguration
> {
>     String getLinkLabelFormat();
> }
>
> public class DefaultRenderingConfiguration implements Initializable,
> Reloadable, RenderingConfiguration
> (in practice will extend AbstractConfiguration class probably)
> {
>     private String linkLabelFormat;
>
>     // Injected
>     private ConfigurationManager manager;
>
>     public void initialize()
>     {
>         // Define the Configuration sources here. Default
> configuration sources would be defined in AbstractConfiguration
> probably)
>         List configurationSources = ....
>
>         // Configuration namespace (all properties should start with
> the namespace value)
>         String namespace = "rendering";
>
>         reload();
>     }
>
>     // Should be located in AbstractConfiguration
>     public void addConfigurationSource(ConfigurationSource source);
>
>     public void reload()
>     {
>         // Populate java bean
>         manager.populate(this, configurationSources, namespace);
>     }
>
>     public void setLinkLabelFormat(String linkLabelFormat) {...}
>     public String getLinkLabelFormat() {...}
> }
>
> * The DefaultRenderingConfiguration class is registered as a component
> in components.xml and with a singleton lifecycle. This means the data
> it contains are cached for the whole application lifetime. They can be
> reloaded using reload().
> * The ConfigurationManager implementation will use Jakarta BeanUtils
> to automatically populate a javabeans. It'll also use Jakarta Commons
> Configuration for implementations of ConfigurationSource.
> * ConfigurationSource interface should have a method like: Object
> getParameter(String name). More details to be defined later.
> * Code wanting to get Rendering Configuration would simply define a
> component dependency on DefaultRenderingConfiguration and they'll have
> it injected for them.
> * There'll be a XWikiDocumentConfigurationSource that gets parameter
> values from one or several xwiki documents. We'll need to define how
> we get them but we could provide some standard XWikiConfigurationClass
> for a single configuration element for example.
> * The idea of the namespace is to use the package name and remove the
> "org.xwiki" or "com.xpn.xwiki" prefix. For example
> "org.xwiki.rendering.*" leads to "rendering.*".
>
> WDYT?
>
> If we agree I can whip up a first implementation of this relatively
> quickly I think.
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to