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