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
