Sean Gilligan wrote:
Do you mind me asking what a namespace is and how it might be relevant
to Roller?
A namespace is a way to group common actions, i.e. books/*. For simple
applications, it doesn't add anything.
2) View independence through the SpringMVC View interface.
In WebWork 2, this is called a Result, and we have builtin support for
JSP, Velocity, Freemarker, JFreeChart, Jasper, XSLT, and a few others.
The current Roller blog UI uses a VelocityContext as its "result", which
easily maps to the Java Map interface which is what SpringMVC uses as
the "Model" in its ModelAndView return type. Can a result be just a Map?
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.
I don't know what the extra steps would be, but in looking through the
Manning book at Borders, I got the impression that when using WebWork
you had to learn the WebWork abstractions and model to even do a simple
application, whereas with SpringMVC the Controller is a lot like a
Servlet. That was my impression, but, since I haven't really started
anything with it, I don't really know what I'm talking about...
All you really need to know is Action and how to write its config in xwork.xml,
and even implementing Action is optional. WW is really good about letting you
only deal with POJO's and it sounds like for your app, that'd be fine. And
really, Struts Action 1's Action, WW's Action, and Spring's Controller are all
pretty much just like a Servlet.
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.
That said, if Roller is considering upgrading to Struts Action 2, I'd
be more than happy to help out, as it would help us focus our
migration tools simultaneously.
I'd definitely like to see the Roller admin be ported to WW2/SAF2 since
I'm trying real hard to avoid learning Struts 1.x ;)
I'm prepared to sign up to finish the port of the Blog UI component to
SpringMVC, but don't think I'll have the time to learn WW2 and do the
work. 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.
Good luck!
Don
One neat feature (at least on paper, since I haven't used it yet) of
SpringMVC is that it has a mechanism for integrating Controllers/Actions
from other frameworks through something called a HandlerAdapter. Is
there something like this in WW2?
Perhaps, we (I) could finish the SpringMVC refactoring and then later,
once the admin UI is in WW2/SAF2 we could integrate it using an adaption
mechanism or just port it over to WW2.
In any case, moving the "view" code into a separate class from the
"controller" (Servlet) would be a step in the right direction.
Thanks, again,
Sean
