I have a remark: from my experience, in big projects, people tend to create lots of configuration files for each modules and at the end it appears to be really hard to maintain something coherent and easy to use. You spend more time looking in files to find the parameter you need to change and if documentation is not perfect, this can become totally impossible for a non-expert. imagine if you have 50 modules, you may have 50 different places for configuration?
So will it be possible to aggregate configurations to centralize data and optimize configuration mechanisms? regards Pascal On Mon, Aug 25, 2008 at 2:17 PM, Marius Dumitru Florea < [EMAIL PROTECTED]> wrote: > Hi Vincent, > > I like it. Just make sure this configuration components will be available > in velocity code as well. As you know, I had to write a plug-in for the > WYSIWYG mainly because currently there's no way of getting a XWiki > configuration parameter without having programming rights. Also, I think > we should allow a configuration source to contain parameters for different > modules. But I guess this is easy to implement using the namespaces you > mentioned. > > So I'm definitely +1. > > > 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 > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
