David M Johnson wrote:
Comments below...
On Mar 5, 2006, at 12:09 PM, Anil Gangolli wrote:
Taking this path would suggest that we use Spring's xml-based
configuration mechanisms instead of roller.properties. It's possible
(as Matt has done for some of the Acegi-related properties) to support
configuration via roller.properties rather than requiring users to
edit the xml, but I think that the approach taken by Matt for the
security props (having code in RollerContext initialization read the
roller props and call appropriate bean setters) would be onerous to
extend to a large number of properties. What would probably work
nicely (and be easy) is to have most of the Spring configuration refer
where necessary (by property paths) to one bean representing the
equivalent of roller.properties and configured in one xml file (or
even a properties file if we initialize that one bean specially).
I had to review my Spring book a little to understand what Anil is
talking about here. (There is a PropertyPathFactoryBean that can peel
off a single property from a Properties, Map, etc. for injection into
another bean -- this allows objects configured through D.I. in the
XML-based container to use individual properties defined in a
.properties file without injecting the whole Properties object.)
I'm guessing the consensus will be to leave roller.properties as a
.properties file for the foreseeable future.
I think there are three types of configuration properties in
roller.properties:
1 - implementation class names, e.g. which persistence implementation to
use
2 - configuration properties that rarely change or cannot be changed at
runtime
3 - obscure configuration properties that don't warrant a place in the UI
For #1 type properties, I wouldn't mind asking users to edit
Springhetti-style XML. Folks who want to substitute their own
implementations clearly know what they are doing and can handle the XML.
Maybe we can make Roller easier to customize and perhaps all major
Roller sites need extensive customization. But for type #2 and #3, is it
really better to have folks editing XML instead of a drop-dead simple
properties file?
For #2 and #3 you could leave some or all of these properties in one or
more .properties files. Spring doesn't force you to use XML for simple
property definitions. You can use Anil's recommended technique above or
several others to achive this.
-- Sean
