Allen Gilliland wrote:
My initial opinion is still "mixed bag", but I am definitely willing to
hear more about how you would want to integrate Spring. I still haven't
really done much with Spring, but I do see some ways in which it could
be useful to Roller.
On Sun, 2006-03-05 at 09:09, 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).
My personal opinion is that we can do this without Spring using a little
bit more of our own code. Of course it's nice to have the work already
done for us by Spring instead.
One question I have is are there any controls on what beans someone can
access via Spring? i.e. if I use appfuse as an example I noticed that
there is a bean defined for the Hibernate sessionFactory. is there
anything that prevents someone in the presentation layer from trying
ctx.getBean("sessionFactory")? that is one thing that I wasn't sure
about.
We could control context population as we want. Not all Spring beans
are necessarily exposed in the velocity context.
The nice thing about using a normal Java based hierarchy for accessing
objects is that nobody can access objects that they aren't supposed to
know about. Another example from appfuse would be the way that the app
separates out a "service" and "dao" layer, what prevents someone from
directly accessing a dao bean even though they aren't supposed to?
I'm not really familiar with AppFuse's model; I'd guess Matt R is :-)
and could answer with respect to that. Spring beans are just plain Java
classes that happen to be instantiated and configured by Spring. We can
choose our own structure. If we choose to use Spring MVC or some other
model in addition to basic beans, that would place more structural
constraints and choices we would be adopting as a result, but this is
independent. I'm not advocating that but we might want to consider that
later too; I haven't really used it in the realm of presentation. I
have used the basic BeanFactory and ApplicationContext mechanisms quite
a bit now mostly for backend database apps that have little or no user
interface. They're great.
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).
This is the other big thing that I am concerned about with Spring in
Roller. I really don't want go back to making the config more
complicated and spread out.
It would be just as centralized as roller.properties /
roller-custom.properties but as xml. In fact with a bit of simple
development we could even stick with the present property file form for
the few properties that we think should be exposed to site admins, so
this wouldn't have to change. Developers/customizers would see the full
range of Spring however.
I'd like to see more details about the implementation before making any
final decisions though. It's probably not a big deal if the only use of
the Spring appliction context is to inject special overrides for classes
like RollerImpl, ManagerImpls, etc. Since these classes really don't
need to be modified by normal users we can just leave it up to advanced
users to know how to open up the webapp and modify the Spring
Application context to make these customizations.
The roller.properties would still serve its primary purpose, which is to
make it easy for Roller admins to easily apply settings for the things
we expect people to want to change.
Yes, that's the intent there.
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 would definitely like to see it.
-- Allen
--a.
