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 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.
--a.
- Spring and Roller Anil Gangolli
-
