On Aug 25, 2008, at 11:32 PM, Pascal Voitot wrote: > 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?
Yes the idea is to have some predefined locations: * a global xwiki.properties file * some xwiki documents (not fully defined yet, need to read again sergiu's proposal since he had proposed some locations) BTW this is already done in the DefaultConfigurationSourceCollection class :) Thanks -Vincent > 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
