Hello Xwikians,
just a small Idea, but you could also use Java Annotations to Accomplish
this.
E.G.: Create a Annotation Type @Option and annotate Fields and or
getters and setters with it. One can also use more Annotations like
@OptionFormat, or @OptionType etc.
I have implemented something similar with this Mechanism and the nice
thing about this is, that it is more declarative, and option setting and
getting can be generalized and made generic via reflection.
I can show some examples if you like tomorrow.
Good night,
Jonas
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs