I actually have a custom version of Roller running using Spring and I
am more than willing to contribute the code I wrote or otherwise
assist with Spring. I've been using Spring for a over a year now on
many projects though I am by no means an expert. I think it is by far
the best designed, most elegant library I ever used. Or maybe it's
the design pattern it implements. :)
The main benefit I see in adopting Spring is its declarative
transaction management. That means Roller.commit() and Roller.rollback
() methods will no longer be necessary. I also see some benefit in
being able to plug in various bits of Roller a little easier since
all you'd need to do is edit XML-based config file. I've never used
SpringMVC (the web framework part) but I know Spring has support
classes for other presentation tier technologies (Struts, JSF and
Velocity) allowing you to configure those components in DI fashion.
Here is what I had to do to introduce Spring into business logic tier
(basically manager classes):
1) Wrote SpringProxyRoller which implements Roller. It loads Spring
bean factor via BeanFactoryLocator mechanism and obtains the real
SpringConfiguedRoller implementation which has all the collaborators
(managers and Hibernate SessionFactory) injected by Spring. All
methods of Roller interface are dispatched to SpringConfiguredRoller.
2) Wrote a SpringHibernatePersistenceStrategy which uses Spring-
provided Hibernate support classes to obtain Hibernate Session
object. Assuming manager objects are properly wired in XML file
(wrapped by the appropriate AOP-based proxies) that gets you
declarative transaction management.
Basically, very little, if anything, in the rest of Roller needs to
change. The only thing is that Roller.commit() and Roller.rollback()
are ignored, and top-level methods in Manager classes become
transaction boundaries. By top-level methods I mean methods called
from Struts actions.
Max
On Mar 7, 2006, at 2:42 PM, Sean Gilligan wrote:
David M Johnson wrote:
True, but Anil is enthusiastic and willing to make a specific
proposal. If it makes Roller easier to test, maintain or customize
then it's worth considering pulling in other parts of Spring.
Spring is a collection of frameworks and utilities and we're
already using some of that now. Plus, we're shipping the complete
spring.jar with Roller (so we can use Acegi).
So, my first reaction -- "not another framework" -- was really
about Spring MVC. We already have a Web/MVC framework.
The way that I'm thinking of using SpringMVC is extremely simple
and shouldn't be compared to Struts or most other MVC frameworks.
What I'm working on is really just a thin wrapper around the
Servlet interface, sort of a Servlets++. At this point, my sandbox
refactoring is mixing in 3 classes and two interfaces from
SpringMVC into org.roller.presentation.velocity -- a total of about
6 method calls to learn. The biggest impact is that the Velocity
Context is being replaced by a Map/HashMap in many existing classes.
I should be able to get a detailed proposal and possibly a proof-of-
concept (probably non-working) patch just to give you an idea of
how simple this is and the benefits received in flexibility and
view independence.
If I thought a using a
framework instead of our page servlets would improve Roller (maybe
it does), I would be investigating the new Struts2/WorkWork stuff.
> That
> should (?) be the easiest migration path for our existing Struts
UI and
> couldn't it do pretty much the same things as Spring/MVC for our
> page/feed rendering code? That's an honest question -- I don't
know the
> answer.
I don't know the answer either -- I looked at WebWork briefly and
it doesn't seem to have this thin-wrapper-around-Servlets subset
that applies well to org.roller.presentation.velocity. But I might
have missed something.
Once I submit my proposal, if someone points out a way to achieve
similar results with Struts2/WebWork, then I'm all for it (but may
not commit to writing *all* of the code ;))
I am enthusiastic and willing to make a specific proposal :) I
just need a few more days.
Regards,
Sean
