You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Sean Gilligan <se...@msgilligan.com> on 2006/05/03 00:25:32 UTC
New URLs and SpringMVC Proposal
Hi Allen, et. al.,
I responded to Allen's comments on the NewUrlStructure page of the wiki:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_NewUrlStructure
and started a Proposal for using Spring MVC:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_VelocityToSpringMVC
I'm quite busy for the next two weeks, but will be able to work with
Allen (and others) to flesh out/discuss the proposal. However, I can
commit to coding/helping with the Spring MVC implementation for the
Roller 3.0 release.
It seems to me that one of the next steps is to see if the
SimpleUrlHandlerMapping will work for the proposed new URL structure. I
should have the time to write the XML configuration for the mapping
sometime tomorrow. Creating the full Spring config file for the web
layer, roller-servlet.xml (or whatever it will be called) and changes to
web.xml would be the step after writing the URL matching strings for
SimpleUrlHandlerMapping.
Although I believe SpringMVC will help with URL mapping, the main
reason I am proposing is because I believe view-layer independence is a
compelling reason for considering this proposal. I'm not saying we want
to move away from Velocity in the short term, but I think the Roller
codebase should keep the view layer "pluggable" just in case. It means
that the Roller blog engine could be used with a different template
engine than Velocity, not that we would be forcing any existing sites to
migrate.
Regards,
Sean
Re: New URLs and SpringMVC Proposal
Posted by Ted Husted <te...@gmail.com>.
On 5/3/06, Sean Gilligan <se...@msgilligan.com> wrote:
> I've taken a serious (but probably not long enough) look at WebWork, but
> I haven't seen anything specific about what's coming with the
> Struts/WebWork merger. Can someone provide information/links on this?
In the first phase, we're just repackaging the framework as an Apache
Struts product and resolving any licensing issues, so that it can be
distributed under the Apache License, without any encumbrances. We're
hoping to wrap phase 1 up by August. The SAF 2.0 release would be the
technical equivalent of WW 2.3.
There are other API changes being discussed for "phase 2",
* http://wiki.apache.org/struts/RoughSpots
but Job One is getting out a stable ASF release that we can start
using right away.
> In looking at WebWork, it seemed to me that you are forced into much
> more abstraction from HttpServletRequest etc. than we really need for
> the blog UI and that it would be a much bigger change to the existing code.
Actually, acquiring the HttpSerlvetRequest is one line of code, just
like anywhere else.
{{HttpServletRequest request = ServletActionContext.getRequest();}}
We do encourage a higher-level of abstraction, but everything you
would need is provided through the ServletActoionContext, if that's
what you need to do.
For more see
* http://confluence.twdata.org/display/WW/How+can+I+get+the+HttpServletRequest
>
> It would be great if someone that knows WebWork (or SAF 2.0?) could take
> a look at my proposal and provide some guidance into how WebWork/SAF2
> could be used to do something similarly lightweight. If not, do we have
> the resources (I'm willing to help, but will be of much less value) to
> do a WebWork/SAF2 implementation of the blog UI?
I'm trying to wrap-up a preliminary pass on the SAF2 wiki right now,
but as soon as that is done, I will take a close look at the proposal.
-Ted.
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Sean Gilligan wrote:
> 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.)
Migration is something that WebWork never took too seriously, and that will
definitely change in Struts Action 2. We are trying to combine the next
generation feature you'd expect with a smooth migration path for existing Struts
and WebWork users (and possibly Spring MVC, actually). We had initially tried
to work with Spring MVC through the "Clarity" initiative, but that didn't go
anywhere unfortunately.
Don
>
> -- Sean
>
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Sean Gilligan <se...@msgilligan.com>.
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
Re: SpringMVC or WebWork/SAF2 planning
Posted by Ted Husted <te...@gmail.com>.
On 5/9/06, Don Brown <mr...@twdata.org> wrote:
> Noel J. Bergman wrote:
> >> At the end of the day, those willing to do the work make the
> >> decisions, so let me know how/if I can help.
> >
> > In other words, you're offering to be one of the people doing the work?
>
> But of course :)
>
> Don
I intend to become more active with Roller again myself. I've just
been heads-down with WebWork and SAF2 work lately.
* http://confluence.twdata.org/display/WW/Home
* http://confluence.twdata.org/display/EDU/MailReader+Training+Course
Our PlanetStruts site is still chugging along on Roller, and I'd like
to do whatever I can to make Roller a continued success.
-Ted.
http://www.planetstruts.org/
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Noel J. Bergman wrote:
>> At the end of the day, those willing to do the work make the
>> decisions, so let me know how/if I can help.
>
> In other words, you're offering to be one of the people doing the work?
But of course :)
Don
>
> --- Noel
>
>
RE: SpringMVC or WebWork/SAF2 planning
Posted by "Noel J. Bergman" <no...@devtech.com>.
Don Brown wrote:
> > To be clear, are you saying that Sean could do less work -- and
> > work that he would be doing anyway -- and that you are offering
> > to help do the neccessary work to do the SAF2 bits, educating the
> > Roller team in the process?
> Sure, I'll help in any way I can.
> However, I wouldn't move to Struts Action 2 today (unless you want
> to be really cutting edge) :), so that leaves WebWork 2 and Spring.
> Moving to WebWork will get you 90% of the way to Struts Action 2
> however, if you'd rather just go with something that is more
> familiar, I'd completely understand.
I'm not sure that I'm seeing an expression about familiarity with SpringMVC
as much as a lack of same with WW2/SAF2, and the perception (which you seem
to be saying is false) that WW2/SAF2 is harder.
> At the end of the day, those willing to do the work make the
> decisions, so let me know how/if I can help.
In other words, you're offering to be one of the people doing the work?
--- Noel
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Noel J. Bergman wrote:
> Don Brown wrote:
>> Sean Gilligan wrote:
>>> Don Brown wrote:
>>>> 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'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.
>> 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.
>
> To be clear, are you saying that Sean could do less work -- and work that he
> would be doing anyway -- and that you are offering to help do the neccessary
> work to do the SAF2 bits, educating the Roller team in the process?
Sure, I'll help in any way I can. However, I wouldn't move to Struts Action 2
today (unless you want to be really cutting edge) :), so that leaves WebWork 2
and Spring. Moving to WebWork will get you 90% of the way to Struts Action 2,
however, if you'd rather just go with something that is more familiar, I'd
completely understand.
I don't know Spring MVC, but Spring as a project is pretty good about staying
out of your code, as is WebWork, so whatever you choose, it should be pretty
trivial to switch from one to another.
At the end of the day, those willing to do the work make the decisions, so let
me know how/if I can help.
Don
>
> --- Noel
>
>
RE: SpringMVC or WebWork/SAF2 planning
Posted by "Noel J. Bergman" <no...@devtech.com>.
Don Brown wrote:
> Sean Gilligan wrote:
> > Don Brown wrote:
> > > 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'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.
>
> 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.
To be clear, are you saying that Sean could do less work -- and work that he
would be doing anyway -- and that you are offering to help do the neccessary
work to do the SAF2 bits, educating the Roller team in the process?
--- Noel
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
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
>
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Allen Gilliland wrote:
> The url space is going to be so virtual that we need to inspect all
> requests (/*) and we only want to take special action on a subset of
> those requests. If I map /* to the Spring or WebWork dispatcher servlet
> then I can't let my servlet container handle things like static files
> (/foo.png).
First, the recommended way to use WebWork is as a servlet filter -
FilterDispatcher. Second, it sounds like you'd want to code your own
ActionMapper to have complete control over how WebWork turns a URL into an
action and namespace.
> Hmm, I didn't get that same impression from my initial look. I want to
> make clear that I am not saying that WW is not flexible enough to let
> the user configure things however they want, but what I am saying is
> that the defaults in WW seem more elaborate than Spring.
What Ted is saying is that you can have your action use _no_ interceptors and
basically get cut out most of the features WebWork provides. What particular
elaborate defaults are you referring to?
> I think the one nice thing that Spring does here that WebWork doesn't is
> that it provides a pluggable ViewResolver. The ViewResolver is just the
> logic that maps a result code to a Result and can be unaware of how the
> actual Result is implemented.
>
> AFAIK you can't do that in WW so we would have to define a custom Result
> which inspects result codes and then somehow passes on to another set of
> classes to do the actual rendering.
>
> This is important because the result codes we are probably going to
> return are going to be custom and very dynamic. like ...
> "velocity:basic:weblog" or "velocity:0112f2dd0ad732dc010ad733f9be0001"
This is interesting and you are right, something WebWork doesn't seem to support
out of the box. You could, as you said, use a custom result which inspects the
result name and delegates to the appropriate Result. You could also extend the
DefaultActionInvocation, which controls the Action, Interceptor, Result process
flow, and inject code to be more intelligent on choosing a Result.
Hope that helps,
Don
Re: SpringMVC or WebWork/SAF2 planning
Posted by Allen Gilliland <al...@sun.com>.
More comments inline.
Ted Husted wrote:
> Comments inline.
>
> On 5/11/06, Allen Gilliland <al...@sun.com> wrote:
>> I'm still doing some prototyping for both Spring and WebWork
>> implementations of what I want to do and I certainly wouldn't mind a
>> little guidance on the WebWork side if you have the time. I think the
>> best thing would be for me to describe the problem a little bit and hear
>> how you might solve it in WebWork.
>>
>> Right now Roller uses about 6 different Servlets to serve up all of the
>> user generated weblog content and currently we are using pure Velocity
>> via the VelocityServlet. Basically the process is ...
>>
>> 1. request comes in
>> 2. validate request and parse out some data we want
>> 3. load up velocity context based on the needs of the request
>> 4. lookup template used to render the view
>> 5. render template output to response
>> 6. return response
>>
>> All of that happens in each of these servlets and is tailored towards
>> the specific type of content being served up for the request.
>>
>> *The Problem*
>> I would like to do just enough work to get some view independence in the
>> process described above so that instead of assuming Velocity for
>> everything we can provide an option to use various view technologies.
>> In this case we are only concerned with templating technologies like
>> Velocity, FreeMarker, etc, so we would never use jsps for example.
>>
>> The additional task is that our new url structure is very virtualized
>> and will require some kind of Filter that can inspect incoming requests,
>> figure out if they are a virtual url, and dispatch them if needed. So
>> far, none of the canned url mapping tools from any framework appears to
>> provide enough flexibility to do what we need, so I am currently
>> assuming that part will have to be custom.
>
> The entire WebWork/SAF2 architecture relies on the Filter pattern. We
> call our implementation "Interceptors", but they can be used just like
> Filters, but without acquiring a dependency on HTTP (unless you want
> one!).
>
> Interceptors are very easy to write and plug into the framework. In
> fact, almost *all* of the framework's funcationality is plugged in
> through Interceptors. Each application can decide for itself exactly
> which Interceptors it needs (or doesn't need).
I know that both Spring and WebWork offer easy configuration for
interceptors and they sound like a great feature which indeed functions
basically the same way as a servlet filter. However, my understanding
is that in both Spring and WebWork the request is supposed to get to a
dispatch servlet, then it may pass through a series of interceptors
during it's handling.
This actually doesn't work for us because we need to filter entries
*before* they get to an actual servlet endpoint. That's why we need a
true servlet filter.
The url space is going to be so virtual that we need to inspect all
requests (/*) and we only want to take special action on a subset of
those requests. If I map /* to the Spring or WebWork dispatcher servlet
then I can't let my servlet container handle things like static files
(/foo.png).
>
>>
>> It's also important to note that our real goal here is simplicity,
>> control, and speed. The content we are rendering is entirely dynamic,
>> so we need to be flexible. We aren't doing anything fancy here either,
>> no form processing, chaining, etc, basically just lookup the data,
>> render it, return it. This part of Roller represents about 95% of the
>> applications usage, so we want it to be as simple and streamlined as
>> possible yet allow us enough control to hack it however is needed for
>> optimization.
>
> As mentioned, it's very easy to optimize the WebWork/SAF2 "pipeline"
> by being selective about which Interceptors are included. The set of
> Interceptors can be adjusted on an action-by-action basis, making the
> architecture as flexible as it gets.
In truth, I don't think that interceptors are something we would make
extensive use of in this particular component of the UI. In the
publishing interface definitely, but in the content delivery component I
don't think we would really need them much if at all.
>
>>
>> *The Spring Approach*
>> I call Spring "lightweight" because 1) it has minimal dependencies in
>> the form of jars, configs, etc and 2) because the code it uses is not
>> very intrusive. By intrusive I mean it doesn't try and do things for
>> you or ask you to tailor much of your code in the Spring pattern, and it
>> doesn't make many assumptions about how you should (or want to) use the
>> framework.
>
> Ditto for WebWork/SAF. Almost *nothing* is hardwired, and almost
> *everything* is optional. We have a default configuration that most
> applications use "out of the box", but it's just as easy for an
> application to pick and choose exactly which features are needed.
Hmm, I didn't get that same impression from my initial look. I want to
make clear that I am not saying that WW is not flexible enough to let
the user configure things however they want, but what I am saying is
that the defaults in WW seem more elaborate than Spring.
>
>
>>
>> So, in Spring our VelocityServlets would become Spring Controllers and
>> those controllers can function exactly as they do now, except that they
>> would use a generic Map instead of a VelocityContext object for loading
>> the model. Then instead of doing steps 4 & 5 in the Controller they
>> will dispatch to a View object instead.
>>
>> This requires fairly minimal effort because we simply rename a few
>> things to turn the servlets into Controllers, and the effort to use a
>> Map instead of a VelocityContext is a good thing no matter what
>> framework we choose. We also have simple and flexible view independence
>> because we can simply have the controllers return any variation of View
>> that we want.
>>
>> I don't know the full details of how the url mapping will get flushed
>> out. So far it still looks like we'll need some kind of custom filter
>> to at least to the first part of the mapping and get requests forwarded
>> to the appropriate servlet destination.
>
> The WebWork/SAF2 approach might be to use "Results" to accomidate
> different types of output. There is already a VelocityResult that does
> what you describe.
I have looked at that VelocityResult and it won't work for us for a
couple reasons.
1. we don't have an easy way to map result codes to this result.
explained more below.
2. the way our decorating stuff works means we would have to make
customizations to the Velocity rendering process, so it's very doubtful
we could just use this canned Result.
>
> The Results are plugged in, like everything else. The output of the
> servlets would be represented as different Result Types. I expect that
> either an Interceptor or an Action would determine which Result is
> need to service a request, and then the framework would select the
> appropriate Result.
>
> From what you've described so far, I suspect that we might be able to
> use a single Action to service the requests, which would then select
> the appropriate Result Type. The six servlets would map to six Result
> Types, and more could be plugged in as needed.
But wouldn't the more standard way be to use 6 actions and have each
Result represent a different view technology. i.e. your example of
VelocityResult?
It also seems like the action is meant to be View agnostic, so the real
logic of view handling is done by a Result. So perhaps what we would
need is a RollerResult class which takes the result code from the Action
and determines how best to render it?
>
> In brief, the typical request lifecycle runs something like this:
>
> * The URI requested is mapped to an action. The action includes a Java
> handler that can be used to access a database and so forth.
This is always done via a dispatcher servlet correct? so you map /foo/*
to dispatcher servlet in the web.xml and the dispatcher will analyze the
url again and map to an action?
>
> * The handler's execution is wrapped in a set of "Interceptors" that
> fire before and after the handler, like a filter. The Interceptors
> provide cross-cutting features that actions might want to share, like
> validation, property population, and security. Interceptors can also
> use "dependency injection" to set properties on the Action handler
> before it executes. All Interceptors are optional. Each action can
> have it's own set of Interceptors.
>
> * After the Action executes, it returns a String indicating which
> Result should be used. There are several predefined result types,
> including Velocity or FreeMaker templates, JavaServer Pages,
> JasperReports, and so forth. Other Result Types can be plugged in as
> needed.
I think the one nice thing that Spring does here that WebWork doesn't is
that it provides a pluggable ViewResolver. The ViewResolver is just the
logic that maps a result code to a Result and can be unaware of how the
actual Result is implemented.
AFAIK you can't do that in WW so we would have to define a custom Result
which inspects result codes and then somehow passes on to another set of
classes to do the actual rendering.
This is important because the result codes we are probably going to
return are going to be custom and very dynamic. like ...
"velocity:basic:weblog" or "velocity:0112f2dd0ad732dc010ad733f9be0001"
>
> * The selected Result is responsible for returning the response to the
> client's request, or transfering control to another resource.
what kind of other resources would a Result transfer to? does WW define
a standard or is that something custom?
-- Allen
>
> * The framework also provides for declarative exception handling. If
> the Action handler throws an Exception, it can be automatically mapped
> to another Result, which can log and display the error. Different
> types of Exceptions can be mapped to different Results.
>
> For more on the WebWork/SAF2 architecture, see
>
> * http://confluence.twdata.org/display/WW/Architecture
>
> As an aside, the framework already depends on the technologies you've
> mentioned. We use Velocity or FreeMarker under-the-hood to create our
> custom UI tags, and many WebWork developers are loyal template users.
>
> We also use Spring as the framework's internal object fractory, and we
> also expose Spring to the application. The Spring support in
> WebWork/SAF is as seamless as the Spring support in Spring MVC!
>
> It's possible that other popular framework add-ins, like SiteMesh,
> might help simplify other Roller features like themes.
>
> -Ted.
Re: SpringMVC or WebWork/SAF2 planning
Posted by Ted Husted <te...@gmail.com>.
Comments inline.
On 5/11/06, Allen Gilliland <al...@sun.com> wrote:
> I'm still doing some prototyping for both Spring and WebWork
> implementations of what I want to do and I certainly wouldn't mind a
> little guidance on the WebWork side if you have the time. I think the
> best thing would be for me to describe the problem a little bit and hear
> how you might solve it in WebWork.
>
> Right now Roller uses about 6 different Servlets to serve up all of the
> user generated weblog content and currently we are using pure Velocity
> via the VelocityServlet. Basically the process is ...
>
> 1. request comes in
> 2. validate request and parse out some data we want
> 3. load up velocity context based on the needs of the request
> 4. lookup template used to render the view
> 5. render template output to response
> 6. return response
>
> All of that happens in each of these servlets and is tailored towards
> the specific type of content being served up for the request.
>
> *The Problem*
> I would like to do just enough work to get some view independence in the
> process described above so that instead of assuming Velocity for
> everything we can provide an option to use various view technologies.
> In this case we are only concerned with templating technologies like
> Velocity, FreeMarker, etc, so we would never use jsps for example.
>
> The additional task is that our new url structure is very virtualized
> and will require some kind of Filter that can inspect incoming requests,
> figure out if they are a virtual url, and dispatch them if needed. So
> far, none of the canned url mapping tools from any framework appears to
> provide enough flexibility to do what we need, so I am currently
> assuming that part will have to be custom.
The entire WebWork/SAF2 architecture relies on the Filter pattern. We
call our implementation "Interceptors", but they can be used just like
Filters, but without acquiring a dependency on HTTP (unless you want
one!).
Interceptors are very easy to write and plug into the framework. In
fact, almost *all* of the framework's funcationality is plugged in
through Interceptors. Each application can decide for itself exactly
which Interceptors it needs (or doesn't need).
>
> It's also important to note that our real goal here is simplicity,
> control, and speed. The content we are rendering is entirely dynamic,
> so we need to be flexible. We aren't doing anything fancy here either,
> no form processing, chaining, etc, basically just lookup the data,
> render it, return it. This part of Roller represents about 95% of the
> applications usage, so we want it to be as simple and streamlined as
> possible yet allow us enough control to hack it however is needed for
> optimization.
As mentioned, it's very easy to optimize the WebWork/SAF2 "pipeline"
by being selective about which Interceptors are included. The set of
Interceptors can be adjusted on an action-by-action basis, making the
architecture as flexible as it gets.
>
> *The Spring Approach*
> I call Spring "lightweight" because 1) it has minimal dependencies in
> the form of jars, configs, etc and 2) because the code it uses is not
> very intrusive. By intrusive I mean it doesn't try and do things for
> you or ask you to tailor much of your code in the Spring pattern, and it
> doesn't make many assumptions about how you should (or want to) use the
> framework.
Ditto for WebWork/SAF. Almost *nothing* is hardwired, and almost
*everything* is optional. We have a default configuration that most
applications use "out of the box", but it's just as easy for an
application to pick and choose exactly which features are needed.
>
> So, in Spring our VelocityServlets would become Spring Controllers and
> those controllers can function exactly as they do now, except that they
> would use a generic Map instead of a VelocityContext object for loading
> the model. Then instead of doing steps 4 & 5 in the Controller they
> will dispatch to a View object instead.
>
> This requires fairly minimal effort because we simply rename a few
> things to turn the servlets into Controllers, and the effort to use a
> Map instead of a VelocityContext is a good thing no matter what
> framework we choose. We also have simple and flexible view independence
> because we can simply have the controllers return any variation of View
> that we want.
>
> I don't know the full details of how the url mapping will get flushed
> out. So far it still looks like we'll need some kind of custom filter
> to at least to the first part of the mapping and get requests forwarded
> to the appropriate servlet destination.
The WebWork/SAF2 approach might be to use "Results" to accomidate
different types of output. There is already a VelocityResult that does
what you describe.
The Results are plugged in, like everything else. The output of the
servlets would be represented as different Result Types. I expect that
either an Interceptor or an Action would determine which Result is
need to service a request, and then the framework would select the
appropriate Result.
>From what you've described so far, I suspect that we might be able to
use a single Action to service the requests, which would then select
the appropriate Result Type. The six servlets would map to six Result
Types, and more could be plugged in as needed.
In brief, the typical request lifecycle runs something like this:
* The URI requested is mapped to an action. The action includes a Java
handler that can be used to access a database and so forth.
* The handler's execution is wrapped in a set of "Interceptors" that
fire before and after the handler, like a filter. The Interceptors
provide cross-cutting features that actions might want to share, like
validation, property population, and security. Interceptors can also
use "dependency injection" to set properties on the Action handler
before it executes. All Interceptors are optional. Each action can
have it's own set of Interceptors.
* After the Action executes, it returns a String indicating which
Result should be used. There are several predefined result types,
including Velocity or FreeMaker templates, JavaServer Pages,
JasperReports, and so forth. Other Result Types can be plugged in as
needed.
* The selected Result is responsible for returning the response to the
client's request, or transfering control to another resource.
* The framework also provides for declarative exception handling. If
the Action handler throws an Exception, it can be automatically mapped
to another Result, which can log and display the error. Different
types of Exceptions can be mapped to different Results.
For more on the WebWork/SAF2 architecture, see
* http://confluence.twdata.org/display/WW/Architecture
As an aside, the framework already depends on the technologies you've
mentioned. We use Velocity or FreeMarker under-the-hood to create our
custom UI tags, and many WebWork developers are loyal template users.
We also use Spring as the framework's internal object fractory, and we
also expose Spring to the application. The Spring support in
WebWork/SAF is as seamless as the Spring support in Spring MVC!
It's possible that other popular framework add-ins, like SiteMesh,
might help simplify other Roller features like themes.
-Ted.
Re: SpringMVC or WebWork/SAF2 planning
Posted by Matt Raible <mr...@gmail.com>.
For pretty URLs in Roller - I see no harm in using the URL Rewrite
Filter. Does anyone else? If we're using response.encodeURL() on
links, it should handle two-way URL rewriting.
Oh wait... we're an Apache project and it's license is not allowed. Damn.
Matt
On 5/12/06, David M Johnson <Da...@sun.com> wrote:
>
> On May 11, 2006, at 6:37 PM, Allen Gilliland wrote:
> > I don't know the full details of how the url mapping will get
> > flushed out. So far it still looks like we'll need some kind of
> > custom filter to at least to the first part of the mapping and get
> > requests forwarded to the appropriate servlet destination.
>
> Maybe this is a stupid question, but if we can't use an web/MVC
> framework to route our virtual URLs and we don't need form field
> processing, what is the value-add of using an web/MVC framework for
> the page/feed rendering?
>
> - Dave
>
>
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Allen Gilliland wrote:
> To be totally honest, at the current moment I am leaning towards not
> using a framework for this stuff and instead sticking with pure Servlets
> and a little bit of custom code.
From what I'm seeing, I agree with you. If/Once Roller moves to Struts Action
2/WW2, it might make sense to port the code over for consistency, but if the
framework won't be used anywhere else (yet?), I'm not sure the effort and dep
would be worth it.
Don
>
> -- Allen
>
>
>>
>> - Dave
>>
>>
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Allen Gilliland <al...@sun.com>.
David M Johnson wrote:
>
> On May 11, 2006, at 6:37 PM, Allen Gilliland wrote:
>> I don't know the full details of how the url mapping will get flushed
>> out. So far it still looks like we'll need some kind of custom filter
>> to at least to the first part of the mapping and get requests
>> forwarded to the appropriate servlet destination.
>
> Maybe this is a stupid question, but if we can't use an web/MVC
> framework to route our virtual URLs and we don't need form field
> processing, what is the value-add of using an web/MVC framework for the
> page/feed rendering?
Nope, that's not stupid at all, in fact I think that is exactly the
right question to ask.
This discussion initially began from Sean's proposal to use SpringMVC as
the implementation for the new url structure. The reality is that we do
*not* need to use any framework to achieve an implementation of the new
url structure. There is nothing preventing us from using some kind of
custom url mapping filter (like url rewrite) along with our current
velocity servlets just as we do now.
That being said, I think the idea of reorganizing and refactoring some
of the weblog rendering code is probably a good idea at this time. I am
already going to have to make some noticeable hacks to that process as
part of the new urls implementation so it makes sense to evaluate how
best to do that. There are really only 2 *non-required* things that I
would like to achieve while doing the new urls implementation ...
1. Allow for view independence in the rendering process. This basically
means supporting a templating system other than Velocity. Note that I
am not saying that Roller should provide any alternative templating
implementations (like new themes, macros,etc), but the option to easily
allow a Roller admin to use an alternative makes a whole lot of sense.
The key scenerio being that if someone is deciding to start a new Roller
based blog site from Roller 3.x code base then they get a Velocity
templating implementation for free *or* they could decide they want to
use FreeMarker or something else and have the ability to plug that in.
I don't think it is too much work to make this happen and it's a feature
that probably few (or none?) other blog systems provide.
2. I would like to unify some related parts of the rendering process and
make them more cohesive. Namely, I would like to abandon the use of
filters for caching and instead build that functionality into the
rendering servlets themselves.
There is no reason why we can't do this with the code we have today and
I think it makes more sense because the current implementation spreads
out pieces that really belong together. It's much easier to view the
PageServlet and see exactly how it deals with 304 responses, cached
content, and rendering, all in one place. At the end of the day I think
that caching is part of the rendering process and should be more closely
coupled with the rendering servlets.
The additional problem of the way we do caching filters right now is
that it is hard (and hacky) to properly handle cases where there are
exceptions/errors in the rendering process. We have a hacked way of
setting a request attribute (DisplayException) with the exception and
hoping that any downstream filters do the right thing, and i think we
can do better than that.
So that is *why* i am investigating these frameworks. Mainly to see if
they would useful in providing the view independence and/or url mapping.
To be totally honest, at the current moment I am leaning towards not
using a framework for this stuff and instead sticking with pure Servlets
and a little bit of custom code.
-- Allen
>
> - Dave
>
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by David M Johnson <Da...@Sun.COM>.
On May 11, 2006, at 6:37 PM, Allen Gilliland wrote:
> I don't know the full details of how the url mapping will get
> flushed out. So far it still looks like we'll need some kind of
> custom filter to at least to the first part of the mapping and get
> requests forwarded to the appropriate servlet destination.
Maybe this is a stupid question, but if we can't use an web/MVC
framework to route our virtual URLs and we don't need form field
processing, what is the value-add of using an web/MVC framework for
the page/feed rendering?
- Dave
Re: SpringMVC or WebWork/SAF2 planning
Posted by Allen Gilliland <al...@sun.com>.
Don Brown wrote:
> Allen Gilliland wrote:
>> i believe that Spring appears to be the more ideal solution for the
>> Content Delivery component because it is a bit less intrusive, very
>> lightweight, would require minimal code modifications to integrate,
>> and it's whole claim to fame is basically it's model and view
>> independence. i think this is the right combination of features for
>> use in the Content Delivery component.
>
> If you do go this way, please feed back any specific enhancements Struts
> Action 2 could make to be "less intrusive", more "lightweight", and
> better "model and view independence". I haven't used Spring MVC
> personally, but I'm eager to incorporate any improvements they have.
Don,
I'm still doing some prototyping for both Spring and WebWork
implementations of what I want to do and I certainly wouldn't mind a
little guidance on the WebWork side if you have the time. I think the
best thing would be for me to describe the problem a little bit and hear
how you might solve it in WebWork.
Right now Roller uses about 6 different Servlets to serve up all of the
user generated weblog content and currently we are using pure Velocity
via the VelocityServlet. Basically the process is ...
1. request comes in
2. validate request and parse out some data we want
3. load up velocity context based on the needs of the request
4. lookup template used to render the view
5. render template output to response
6. return response
All of that happens in each of these servlets and is tailored towards
the specific type of content being served up for the request.
*The Problem*
I would like to do just enough work to get some view independence in the
process described above so that instead of assuming Velocity for
everything we can provide an option to use various view technologies.
In this case we are only concerned with templating technologies like
Velocity, FreeMarker, etc, so we would never use jsps for example.
The additional task is that our new url structure is very virtualized
and will require some kind of Filter that can inspect incoming requests,
figure out if they are a virtual url, and dispatch them if needed. So
far, none of the canned url mapping tools from any framework appears to
provide enough flexibility to do what we need, so I am currently
assuming that part will have to be custom.
It's also important to note that our real goal here is simplicity,
control, and speed. The content we are rendering is entirely dynamic,
so we need to be flexible. We aren't doing anything fancy here either,
no form processing, chaining, etc, basically just lookup the data,
render it, return it. This part of Roller represents about 95% of the
applications usage, so we want it to be as simple and streamlined as
possible yet allow us enough control to hack it however is needed for
optimization.
*The Spring Approach*
I call Spring "lightweight" because 1) it has minimal dependencies in
the form of jars, configs, etc and 2) because the code it uses is not
very intrusive. By intrusive I mean it doesn't try and do things for
you or ask you to tailor much of your code in the Spring pattern, and it
doesn't make many assumptions about how you should (or want to) use the
framework.
So, in Spring our VelocityServlets would become Spring Controllers and
those controllers can function exactly as they do now, except that they
would use a generic Map instead of a VelocityContext object for loading
the model. Then instead of doing steps 4 & 5 in the Controller they
will dispatch to a View object instead.
This requires fairly minimal effort because we simply rename a few
things to turn the servlets into Controllers, and the effort to use a
Map instead of a VelocityContext is a good thing no matter what
framework we choose. We also have simple and flexible view independence
because we can simply have the controllers return any variation of View
that we want.
I don't know the full details of how the url mapping will get flushed
out. So far it still looks like we'll need some kind of custom filter
to at least to the first part of the mapping and get requests forwarded
to the appropriate servlet destination.
*The WebWork Approach*
Maybe you could offer an overview of how you might do it?
-- Allen
>
> Thanks,
>
> Don
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Allen Gilliland wrote:
> i believe that Spring appears to be the more ideal solution for the
> Content Delivery component because it is a bit less intrusive, very
> lightweight, would require minimal code modifications to integrate, and
> it's whole claim to fame is basically it's model and view independence.
> i think this is the right combination of features for use in the
> Content Delivery component.
If you do go this way, please feed back any specific enhancements Struts Action
2 could make to be "less intrusive", more "lightweight", and better "model and
view independence". I haven't used Spring MVC personally, but I'm eager to
incorporate any improvements they have.
Thanks,
Don
RE: SpringMVC or WebWork/SAF2 planning
Posted by "Noel J. Bergman" <no...@devtech.com>.
Allen Gilliland wrote:
> Noel J. Bergman wrote:
> > But isn't Don saying [that] there isn't anything that SpringMVC
> > makes simple that SAF2 doesn't also make simple, and that he is
> > volunteering to help do the work.
> I don't have enough experience with either of them to answer that with
> any confidence.
Neither do I. I am just responding to what I see being written. In fact, I
believe that I saw Don offer that IF there is something that SpringMVC makes
simpler, that he will make that same area in SAF2 equally simple.
--- Noel
Re: SpringMVC or WebWork/SAF2 planning
Posted by Allen Gilliland <al...@sun.com>.
Noel J. Bergman wrote:
> Allen Gilliland wrote:
>
>> i believe that Spring appears to be the more ideal solution for the
>> Content Delivery component because it is a bit less intrusive, very
>> lightweight, would require minimal code modifications to integrate, and
>> it's whole claim to fame is basically it's model and view independence.
>
> But isn't Don saying that SAF2 also has these same characteristics, and
> more, but since everyone focuses on how SAF2 enables complex applications,
> the fact that it also simple applications simply isn't well understood?
> That's what I was getting from Don: that there isn't anything that SpringMVC
> makes simple that SAF2 doesn't also make simple, and that he is volunteering
> to help do the work.
I don't have enough experience with either of them to answer that with
any confidence. My statement was only based on reading that I have done
and docs that I have browsed. I could certainly be wrong.
-- Allen
>
> --- Noel
>
RE: SpringMVC or WebWork/SAF2 planning
Posted by "Noel J. Bergman" <no...@devtech.com>.
Allen Gilliland wrote:
> i believe that Spring appears to be the more ideal solution for the
> Content Delivery component because it is a bit less intrusive, very
> lightweight, would require minimal code modifications to integrate, and
> it's whole claim to fame is basically it's model and view independence.
But isn't Don saying that SAF2 also has these same characteristics, and
more, but since everyone focuses on how SAF2 enables complex applications,
the fact that it also simple applications simply isn't well understood?
That's what I was getting from Don: that there isn't anything that SpringMVC
makes simple that SAF2 doesn't also make simple, and that he is volunteering
to help do the work.
--- Noel
Re: SpringMVC or WebWork/SAF2 planning
Posted by Allen Gilliland <al...@sun.com>.
Sean's questions still need answering, but I wanted to just throw in my
view on this real quick ...
first off, i consider Roller to have 2 distinct UI components.
1. Content Rendering/Delivery. This is pretty much all of our current
velocity stuff plus some other non-Velocity servlets which handle the
rendering and display of all the actual blog content plus the main page.
2. Content Publishing. This is all of our current struts UI stuff which
comprises the /admin/* and /editor/* interfaces for managing Roller content.
i consider these as separate components because they serve very
different needs and are only tied together by the data they work on.
The Content Publishing component is a much more complex component where
almost every page is an html form which is used for strongly interactive
services. The Content Delivery component is almost as simple as static
content delivery and has little to no interaction at all. so it is my
belief that we should consider these 2 components of the Roller
presentation layer independently.
now getting back to the whole SpringMVC vs WebWork/SAF2 discussion ...
i have been barreling my way through Spring and WebWork docs trying to
get up to speed on these things to see how they would fit into the new
url proposal and ultimately the long term plan for Roller's presentation
layer. so far it is my opinion that we should use both.
i believe that Spring appears to be the more ideal solution for the
Content Delivery component because it is a bit less intrusive, very
lightweight, would require minimal code modifications to integrate, and
it's whole claim to fame is basically it's model and view independence.
i think this is the right combination of features for use in the
Content Delivery component.
i know less about WebWork, but it sounds to me like WebWork would be the
more ideal solution for the Content Publishing component because it
offers a richer set of action and form processing tools. we don't need
model and view independence for the Publishing component so i don't
think Spring makes as much sense here, i also think it would be an
easier transition to WebWork than to Spring, and i like the idea of the
action chaining.
so, to try and narrow the scope of this discussion just a little,
remember that we don't need to make any decisions about what would
happen with the Content Publishing component any time soon. we are not
planning to make any changes there in the near future, so we have time
to evaluate Spring and WebWork some more and see what we like. however,
we should make a decision about the Content Delivery component because
we are planning to do some work there for the new url structure anyways.
-- Allen
Sean Gilligan wrote:
*snip*
>
> 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?
>
> 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
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Sean Gilligan <se...@msgilligan.com>.
Hi Don,
Thanks for the detailed response. WebWork sounds very nice indeed.
Don Brown wrote:
> Overall, you'll find WebWork 2 and Spring MVC more similar than not,
> with generally speaking WebWork 2 providing more features in areas, for
> better, for worse.
>>
snip
>
> Furthermore, WebWork 2 has something similar to the HanderMapping called
> the ActionMapper. This lets you have full control of how actions,
> namespaces, and even parameters are coded into a URL. For example,
> Patrick has developed a restful action mapper that lets you map the URL:
>
> /books/view/book/Foo/chapter/1
>
> to
>
> Namespace: /books
> Action: view
> Parameters: book="Foo", chapter=1
>
Do you mind me asking what a namespace is and how it might be relevant
to Roller?
>> 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?
>>
>> I've spent a little time looking at WebWork 2.x and it seems to me
>> that it requires a greater degree of abstraction from Servlets and
>> HttpServletRequest/Response. That is why, at this point, I believe
>> SpringMVC would be a more natural choice for the BlogUI.
>
> WebWork 2 also gives you access to the HTTP objects if you feel you need
> them either through ServletActionContext.getRequest() or implementing
> RequestAware if you prefer an IoC approach. I'd imagine the migration
> from Servlet to Controller looks about what migrating to a simple Action
> would look like.
>
>> So the question is: Is there a similar "lightweight" architecture we
>> could use based upon WebWork/SAF2.0?
>
> I'm not sure how you could get much more lightweight than WebWork 2, so
> perhaps a list of extra steps or hassles WebWork 2 would make you go
> through would help me answer that question better.
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...
>
>
> 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?
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
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@twdata.org>.
Overall, you'll find WebWork 2 and Spring MVC more similar than not, with
generally speaking WebWork 2 providing more features in areas, for better, for
worse.
Sean Gilligan wrote:
> Don Brown wrote:
>> Sure, what's the question(s)?
>
> Well, I was going to ask what the status of the WebWork/Struts merger
> was, but I did my online research, first. In fact, I went ahead and
> created a Wiki page for an SAF 2.0 implementation of the Blog UI and put
> the links to the relevant Web Pages in the "Background Info and Links"
> section:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_VelocityToSAF2
>
> I'm proposing that the Blog UI module of Roller be rewritten/refactored
> to use a very lightweight implementation of SpringMVC to replace the
> current use of VelocityServlet. The main benefits would be:
>
> 1) URL mapping will not longer be limited by web.xml (it can use the
> SpringMVC HandlerMapping interface or, hopefully, the
> SimpleUrlHandlerMapping implementation)
WebWork 2 defaults to using the FilterDispatcher, which accomplishes the same
task. It allows us to serve static content easily, like Javascript files, from
within the jar. In fact, WebWork in general is well attuned to allowing modules
to be completely self-contained in a jar, which is used to great effect by
applications like JIRA. JIRA allows you to upload a complex plugin, called
macros, by uploading a jar that can have static content, templates, code, and
configuration files.
Furthermore, WebWork 2 has something similar to the HanderMapping called the
ActionMapper. This lets you have full control of how actions, namespaces, and
even parameters are coded into a URL. For example, Patrick has developed a
restful action mapper that lets you map the URL:
/books/view/book/Foo/chapter/1
to
Namespace: /books
Action: view
Parameters: book="Foo", chapter=1
> 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.
> I spent a few hours refactoring in Eclipse and it was pretty easy to
> split the PageServlet into a PageController and a RollerVelocityView.
> Since SpringMVC Controllers and View use HttpServletRequest and
> HttpServletResponse, the refactoring is fairly simple.
>
> I've posted a diff to the Wiki on this page:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_VelocityToSpringMVC
> (although the diffs between PageServlet.java and PageController.java
> don't show because I renamed the file)
>
> I've spent a little time looking at WebWork 2.x and it seems to me that
> it requires a greater degree of abstraction from Servlets and
> HttpServletRequest/Response. That is why, at this point, I believe
> SpringMVC would be a more natural choice for the BlogUI.
WebWork 2 also gives you access to the HTTP objects if you feel you need them
either through ServletActionContext.getRequest() or implementing RequestAware if
you prefer an IoC approach. I'd imagine the migration from Servlet to
Controller looks about what migrating to a simple Action would look like.
> So the question is: Is there a similar "lightweight" architecture we
> could use based upon WebWork/SAF2.0?
I'm not sure how you could get much more lightweight than WebWork 2, so perhaps
a list of extra steps or hassles WebWork 2 would make you go through would help
me answer that question better.
I've been talking about WebWork 2 so far, because if you did this today, that is
what I'd recommend. Struts Action Framework 2 is starting with the WebWork
2.2.2 codebase and we are hoping to get a beta release out by JavaOne and GA by
August, which might be too long for your plans. We are taking migration very
seriously both for Struts and WebWork 2 applications, so if you used WebWork 2
today, the amount of work to switch, particularly in your case, would take
probably just a few minutes.
>
> I've created a Wiki page for a SAF 2.0 implementation, so it would be
> great if you or anyone else (Matt?) would be willing to fill in some
> details there.
>
>>
>> If this is about Roller moving to WebWork/SAF 2.0, I actually put in a
>> JavaOne proposal to talk about my experiences migrating Roller to use
>> SAF 2.0, but it wasn't accepted :)
>
> Do you have any URLs, powerpoints, etc. that you put together? How far
> did you get? Is it something you might submit to the Roller project?
No, the plan was if the talk got accepted, that's what I'd be doing for the
months leading up to it. Again, we want to make sure SAF 2 is an easy migration
for Struts apps, and I was thinking that the talk would be good to press the
issue :)
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.
Hope that helps,
Don
>
> Thanks,
>
> Sean
>
Re: SpringMVC or WebWork/SAF2 planning
Posted by Sean Gilligan <se...@msgilligan.com>.
Don Brown wrote:
> Sure, what's the question(s)?
Well, I was going to ask what the status of the WebWork/Struts merger
was, but I did my online research, first. In fact, I went ahead and
created a Wiki page for an SAF 2.0 implementation of the Blog UI and
put the links to the relevant Web Pages in the "Background Info and
Links" section:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_VelocityToSAF2
I'm proposing that the Blog UI module of Roller be rewritten/refactored
to use a very lightweight implementation of SpringMVC to replace the
current use of VelocityServlet. The main benefits would be:
1) URL mapping will not longer be limited by web.xml (it can use the
SpringMVC HandlerMapping interface or, hopefully, the
SimpleUrlHandlerMapping implementation)
2) View independence through the SpringMVC View interface.
I spent a few hours refactoring in Eclipse and it was pretty easy to
split the PageServlet into a PageController and a RollerVelocityView.
Since SpringMVC Controllers and View use HttpServletRequest and
HttpServletResponse, the refactoring is fairly simple.
I've posted a diff to the Wiki on this page:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_VelocityToSpringMVC
(although the diffs between PageServlet.java and PageController.java
don't show because I renamed the file)
I've spent a little time looking at WebWork 2.x and it seems to me that
it requires a greater degree of abstraction from Servlets and
HttpServletRequest/Response. That is why, at this point, I believe
SpringMVC would be a more natural choice for the BlogUI.
So the question is: Is there a similar "lightweight" architecture we
could use based upon WebWork/SAF2.0?
I've created a Wiki page for a SAF 2.0 implementation, so it would be
great if you or anyone else (Matt?) would be willing to fill in some
details there.
>
> If this is about Roller moving to WebWork/SAF 2.0, I actually put in a
> JavaOne proposal to talk about my experiences migrating Roller to use
> SAF 2.0, but it wasn't accepted :)
Do you have any URLs, powerpoints, etc. that you put together? How far
did you get? Is it something you might submit to the Roller project?
Thanks,
Sean
Re: SpringMVC or WebWork/SAF2 planning
Posted by Don Brown <mr...@apache.org>.
Sure, what's the question(s)?
If this is about Roller moving to WebWork/SAF 2.0, I actually put in a
JavaOne proposal to talk about my experiences migrating Roller to use
SAF 2.0, but it wasn't accepted :)
Don
Noel J. Bergman wrote:
> Sean Gilligan wrote:
>
>> I value Matt's opinion highly, so it sounds like we should give
>> some consideration to WebWork.
>
>> I've taken a serious (but probably not long enough) look at WebWork,
>> but I haven't seen anything specific about what's coming with the
>> Struts/WebWork merger.
>
>> It would be great if someone that knows WebWork (or SAF 2.0?) could take
>> a look at my proposal and provide some guidance into how WebWork/SAF2
>> could be used to do something similarly lightweight.
>
> I'm cc'ing Don Brown, who is one of the WebWork Mentors. If he can't answer
> the question(s), I am sure that he can ask some of the SAF 2 gurus to please
> stop by this list with insight and advice.
>
> --- Noel
>
>
SpringMVC or WebWork/SAF2 planning
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sean Gilligan wrote:
> I value Matt's opinion highly, so it sounds like we should give
> some consideration to WebWork.
> I've taken a serious (but probably not long enough) look at WebWork,
> but I haven't seen anything specific about what's coming with the
> Struts/WebWork merger.
> It would be great if someone that knows WebWork (or SAF 2.0?) could take
> a look at my proposal and provide some guidance into how WebWork/SAF2
> could be used to do something similarly lightweight.
I'm cc'ing Don Brown, who is one of the WebWork Mentors. If he can't answer
the question(s), I am sure that he can ask some of the SAF 2 gurus to please
stop by this list with insight and advice.
--- Noel
Re: New URLs and SpringMVC Proposal
Posted by Sean Gilligan <se...@msgilligan.com>.
Dave Johnson wrote:
>
> On May 2, 2006, at 9:19 PM, Matt Raible wrote:
>> IMO, I think it'd be a better move to use WebWork (which also supports
>> Velocity) or rather, SAF 2.0. If/when we migrate from Struts to SAF
>> 2.0 - we could leverage the same framework for both the editor and the
>> blog UI.
>
> Coming from Matt "Spring Live / web framework sweet-spots [1]" Raible,
> that's a telling statement.
Yeah, I value Matt's opinion highly, so it sounds like we should give
some consideration to WebWork.
I should note that the Patrick Lightbody, the WebWork representative in
Matt's paper answers the question "What type of scenarios does [WebWork]
not fit in to? Would you recommend another framework in this scenario?
If so, which one?" with "For a really simple application, I’d recommend
just plain JSP or perhaps Spring MVC if the users are comfortable with
Spring."
The blog UI is pretty simple (VelocityServlet has worked pretty well, it
seems), and JSP is ruled out, so we have a WebWork guy saying that the
"sweet spot" for our application is SpringMVC.
How serious are people about migrating the admin UI to a new framework?
Both the WebWork/Struts merger and SpringMVC are trying to provide a
migration path from "classic" Struts. Has anyone considered SpringMVC
for the admin UI?
Using the same Framework for both blog UI and admin UI sounds desirable,
but what if they have different "sweet spots"?
>
> IMO, *if* we're going to use a framework
I don't think using a framework or not is a binary decision. There are
heavyweight and lightweight frameworks, and some frameworks (SpringMVC)
give you a choice of how much "weight" you want to adopt. I'm proposing
a very lightweight use of SpringMVC. My second choice would be stealing
some design patterns (or interfaces) from SpringMVC and not using a
framework at all. I can't rule out WebWork, though. I think we can
rule out things like Tapestry/JSF for the Blog UI component, though.
> in the implementation of the
> new URL stuff, we should definitely consider the Apache stuff. Why?
> It
> might be better than SpringMVC, it could help us avoid more framework
> proliferation, it's Apache dog food and it might encourage contributors
> from neighboring Apache Struts community (hi Ted!).
I'm a big Apache fan. Spring uses the Apache license and I wish it were
an actual ASF project, but that seems unlikely. However, I think there
is a big overlap between the Apache community and the Spring community.
>
> Sean, have you taken a serious look at what's coming in Struts/Webwork?
I've taken a serious (but probably not long enough) look at WebWork, but
I haven't seen anything specific about what's coming with the
Struts/WebWork merger. Can someone provide information/links on this?
In looking at WebWork, it seemed to me that you are forced into much
more abstraction from HttpServletRequest etc. than we really need for
the blog UI and that it would be a much bigger change to the existing code.
It would be great if someone that knows WebWork (or SAF 2.0?) could take
a look at my proposal and provide some guidance into how WebWork/SAF2
could be used to do something similarly lightweight. If not, do we have
the resources (I'm willing to help, but will be of much less value) to
do a WebWork/SAF2 implementation of the blog UI?
-- Sean
Re: New URLs and SpringMVC Proposal
Posted by Dave Johnson <da...@rollerweblogger.org>.
On May 2, 2006, at 9:19 PM, Matt Raible wrote:
> IMO, I think it'd be a better move to use WebWork (which also supports
> Velocity) or rather, SAF 2.0. If/when we migrate from Struts to SAF
> 2.0 - we could leverage the same framework for both the editor and the
> blog UI.
Coming from Matt "Spring Live / web framework sweet-spots [1]"
Raible, that's a telling statement.
IMO, *if* we're going to use a framework in the implementation of the
new URL stuff, we should definitely consider the Apache stuff. Why?
It might be better than SpringMVC, it could help us avoid more
framework proliferation, it's Apache dog food and it might encourage
contributors from neighboring Apache Struts community (hi Ted!).
Sean, have you taken a serious look at what's coming in Struts/Webwork?
- Dave
[1] http://www.virtuas.com/articles/webframework-sweetspots.html
Re: New URLs and SpringMVC Proposal
Posted by Sean Gilligan <se...@msgilligan.com>.
Matt Raible wrote:
> Then again, code is more powerful than words and I believe
> Sean already has much of the code written for the blog/velocity
> portion.
I haven't really written that much code, just enough to convince myself
(and hopefully others) that SpringMVC is a good solution for the
blog/VelocityServlet part of Roller. There is still plenty of work to
do. However, I am willing to commit to completing the SpringMVC port
for Roller 3.0 if using SpringMVC is approved.
-- Sean
Re: New URLs and SpringMVC Proposal
Posted by Matt Raible <mr...@gmail.com>.
IMO, I think it'd be a better move to use WebWork (which also supports
Velocity) or rather, SAF 2.0. If/when we migrate from Struts to SAF
2.0 - we could leverage the same framework for both the editor and the
blog UI. Then again, code is more powerful than words and I believe
Sean already has much of the code written for the blog/velocity
portion.
Matt
On 5/2/06, Sean Gilligan <se...@msgilligan.com> wrote:
> Noel J. Bergman wrote:
> > Just out of curiousity, why SpringMVC, and not Struts/WebWork and/or JSF?
>
> Because SpringMVC (in its simplest form, which is what I'm proposing) is
> very close to VelocityServlet -- which is how the current code is
> written. It is a request-based framework, and its controllers use
> HttpServletRequest directly, as the current code does. Used in this
> manner, SpringMVC is more of Servlets++ than a full MVC framework.
>
> Why not JSF? The current presentation layer uses Velocity.
> Why not WebWork? We want to use the HttpServletRequest directly
> Why not Struts? I'll let Dave and Allen answer this one
>
> -- Sean
>
Re: New URLs and SpringMVC Proposal
Posted by Sean Gilligan <se...@msgilligan.com>.
Noel J. Bergman wrote:
> Just out of curiousity, why SpringMVC, and not Struts/WebWork and/or JSF?
Because SpringMVC (in its simplest form, which is what I'm proposing) is
very close to VelocityServlet -- which is how the current code is
written. It is a request-based framework, and its controllers use
HttpServletRequest directly, as the current code does. Used in this
manner, SpringMVC is more of Servlets++ than a full MVC framework.
Why not JSF? The current presentation layer uses Velocity.
Why not WebWork? We want to use the HttpServletRequest directly
Why not Struts? I'll let Dave and Allen answer this one
-- Sean
RE: New URLs and SpringMVC Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
Just out of curiousity, why SpringMVC, and not Struts/WebWork and/or JSF?
--- Noel