+1 On Sat, Mar 28, 2009 at 14:50, Vincent Massol <[email protected]> wrote: > Hi, > > So far we've been using plexus configuration mechanism in > components.xml to define component configuration data. I'm proposing > to drop this. Reasons: > 1) This is trying us to plexus and is not generic enough for all IOC > frameworks > 2) It doesn't easily allow overriding config values (for ex if the > user wants to override a value in a wiki page or in xwiki.properties > file) > > I thus propose 3 things: > 1) to use our new xwiki configuration mechanism to store component > configuration data > 2) to have a META-INF/<module prefix>.properties file located in the > module jar where <module prefix> is org.xwiki.rendering for example > for the rendering module (we could also have a submodule if the module > is split into several modules). The idea is that the file name needs > to be unique across jars so that we can create uberjars later on if > need be. > 3) in general we shouldn't have component-specific config data and > instead make the data as generic config data as much as possible and > bound to the module's Configuration component instead. > > For 1) and 2), it's very easy to do: > - the component which requires config data need to have > ConfigurationManager and ConfigurationSources injected and implement > the Initializable interface and then call in initialize(): > > this.configurationManager.initializeConfiguration(this, > this.sourceCollection.getConfigurationSources(), <prefix>); > > - store data using a FQN in META-INF/<module prefix>.properties, for > example: > > org.xwiki.rendering.internal.macro.RealmMacroSource.priority = 10 > > In this example you would call initializeConfiguration with a prefix > value of RealmMacroSource.getClass().getName(). > > 3) is important because otherwise users will be able to override > private config data and if the internal implementation changes the > config data won't be valid anymore. The reason for 2) is to hide these > config data from the users as much as possible since these are > advanced config options that shouldn't normally be used. > For example we would defined a default priority for macros but in some > very exceptional cases the user would want to change the priority so > that the macro executes at a different time for a given reason. > > Another example if the velocity components which contain lots of data. > I believe these data should be moved to a VelocityConfiguration > component instead. > > WDYT? > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
