Just FYI I have started implementing this to see how it went and it's looking very good. Of course, I have some small implementation modifications compared to what I imagined below but the idea and principles stay the same.
Let me know if I should continue and finish it. I reckon I'll need only 1 working day to finish a first working implementation. Thanks -Vincent On Aug 24, 2008, at 6:54 PM, Vincent Massol 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
