Comments below...
On Mar 5, 2006, at 12:09 PM, Anil Gangolli wrote:
I've been using basic Spring dependency injection and
initialization (BeanFactory/ApplicationContext) functionality in
some projects at work and have really been happy with how it
encourages clean modularization and helps me to get more pluggable
reusable components while keeping almost all of the code completely
unaware of Spring itself.
I think using the dependency injection pattern would really help us
clean up interdependencies and make Roller more pluggable and
modifiable. Before spending time on a real proposal, I wanted to
gauge interest in this. Note that this is separable from any
inclination to use Spring MVC (as Sean G is trying) or other Spring
features (like the declarative transaction management that Matt R
suggested).
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 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?
But then again, maybe there are only these two type of properties:
1 - class names and configurations of said classes (perfect for
Spring XML config)
2 - configuration properties exposed through the UI, some of which
require restart (perfect for our XML driven runtime config system)
I think it could be entered gradually, but eventually would mean a
lot of minor-to-moderate restructuring to really utilize the
pattern, feeling kind-of Roller 3.0-ish.
Would there be sufficient support for seeing a proposal along these
lines? I probably won't embark on such a proposal unless there's
some predisposition to move in this direction.
I'm definitely interested in seeing a proposal.
- Dave
