Hi Sergiu, On Aug 24, 2008, at 10:51 PM, Sergiu Dumitriu wrote:

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

[snip]

Looks good. One thing I didn't see there is how to access the configuration from wiki documents. Maybe have a configuration access helper in the velocity context, which can lookup and return configuration components? In this case, we should have some security assertions on those components, maybe using an annotation.

Yes for me all components should be accessible from Velocity. I think they should be put one by one and not the component manager. This will prevent errors and only components we decide will be retrievable. And yes we haven't solved the general question of authentication. I think the best would be to use annotations on public methods with the permission level required to call them or something similar. Not sure yet about the details. For configuration we need to ensure that properties are read only and cannot be set. For example password fields or permission values shouldn't be able to be modified by anyone.

Another thing that isn't quite clear is how to avoid cyclic dependencies, since configuration needs to access wiki documents, which in turn might need some already configured components. Maybe we'll just have to take care of this manually (I don't see any such dependencies right now).

Yes, I have thought about this too but I don't have an answer right now apart the fact that we control the ConfigurationSources used to populate a java bean and that should offer us a little help in some cases. We'll have to handle it as the problem happens. Thanks -Vincent

Hi Jonas, On Aug 24, 2008, at 11:34 PM, Jonas von Malottki wrote:

Hello Xwikians,

just a small Idea, but you could also use Java Annotations to Accomplish this.

Thanks for the idea Jonas!

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.

Yes that would be nice because for now it seems less transparent to what I have (a simple java bean class with all fields being configuration properties). I could see annotation being useful to separate configuration fields from other fields for example but if all of them are configuration properties I don't see the need Thanks again -Vincent

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

I have a remark: from my experience, in big projects, people tend to create lots of configuration files for each modules and at the end it appears to be really hard to maintain something coherent and easy to use. You spend more time looking in files to find the parameter you need to change and if documentation is not perfect, this can become totally impossible for a non-expert. imagine if you have 50 modules, you may have 50 different places for configuration? So will it be possible to aggregate configurations to centralize data and optimize configuration mechanisms? regards Pascal On Mon, Aug 25, 2008 at 2:17 PM, Marius Dumitru Florea < [email protected]> wrote:

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