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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs