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
