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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
