Don Brown wrote:
Sean Gilligan wrote:
WebWork 2 has the ActionContext, which acts like a simple map which you
push things into. Getting down in the weeds, that context is pushed
onto the ValueStack, along with the request parameters, attributes,
action instance, form (optional), etc., from which values are resolved.
Therefore, if you did ActionContext.push("foo", "bar"), then in your
view ${foo}, the ValueStack would look for "foo" in the context, action
instance as a getter (action.getFoo()), request attributes, request
parameters, etc. This abstraction is a powerful way to reduce the
coupling of your view to where the information comes from.
The bottom line is you have choices how you make data available to
Velocity.
Sounds powerful, but a little more complicated than what is (currently)
needed.
In the refactoring hack code that I submitted (and I hope Allen has been
able to successfully view...) I simply changed some of the existing
Roller classes to just use a java.util.Map instead of VelocityContext.
(Although VelocityContext behaves like a Map, it doesn't actually
implement Map...)
As for the book, WW has traditionally targeted the advanced developer
with a complex application, and the book reflects that. One goal in
Struts Action 2 is to better highlight how easy it can be and make it
even easier.
This is a problem with Spring books, too. When you write a framework or
a framework book your focus is on the harder stuff, like trying to make
forms and form processing easy. From my experience, looking at all the
different Controllers in SpringMVC is very intimidating and time
consuming. The books are obligated to cover most of them, but for the
Roller Blog UI, all we need is one: AbstractController.
If I can convince the committers to do it with SpringMVC, what
options does WebWork2 have for integrating SpringMVC controllers?
Honestly, I don't really see the value. For this simple use, there
isn't anything one can do the other can't. I'd say the best bet is to
try to make your class a POJO which could definitely work in WW, and
probably Spring.
If you are set on an adapter, you could easily write an Action instance
that delegated to a Spring controller, but again, you'd have to make the
case clear why a hybrid would be better.
I'm just asking about options that might make it easier to change
directions in the future. I like the way the SpringMVC people try to
give you a migration path from other frameworks. (I'm looking at using
that technique with some Jakarta Turbine Screens and Actions, but
haven't gotten there yet.)
-- Sean
