Ted,
Again, I appreciate the response(s).
>>
In what way would you like them to act on themselves? Initially, the
ActionForward is a way to give a URI a logical name. The ActionServlet
asks for a path, and it is given a path in return. Of course, how that
path is generated is the ActionForward's business. It's really a type of
event object.
<<
There's code in the ActionServlet of the form:
// Execute a forward if specified by this mapping
if (!processForward(mapping, request, response))
return;
// Execute an include if specified by this mapping
if (!processInclude(mapping, request, response))
return;
So we have two calls directly tied to mappings which have known subclasses
of ActionForward. It's "known" (i.e. coupling) that those mappings don't
have Actions and we can skip that stuff. If we get past this in the
ActionServlet, the implicit assumption is that we have a mapping with an
Action and we can go ahead with dealing with the Action, getting the
ActionForward back from it, etc.
It seems to me it would be more flexible and natural if ActionServlet
invoked a method on the ActionMapping that always returned an ActionForward.
The ActionMapping would be responsible for building and calling an Action
when appropriate but in any case would simplify the ActionServlet. As I
think about it, it seems that there should be a Mapping base class from
which ActionMapping is derived. The Forward/Include derivations should be
Mapping derivations which don't have Actions - they just return the
corresponding ActionForward. ActionMapping is a Mapping that does have an
Action and would invoke it:
Mapping
ForwardingMapping
RedirectingMapping
ActionMapping
Code in the ActionServlet would be:
ActionForward forward = mapping.execute(/* stuff */);
ActionMapping.execute() would retrieve the Action and call perform() on it,
returning what it returns. ForwardingMapping.execute() (and
RedirectingMapping.execute()) would simply return the correct derived
ActionForward classes with the configured path. At that point, other types
of mappings become, if you will, first class citizens and can do whatever
they want but still return an ActionForward.
I hope I'm making sense. :)
>>Would it be possible to provide the Velicity service as another servlet
in the application?<<
Absolutely, that's what Geir's example does. And that seems to be the
direction most Velocity folks desire. I understand their viewpoint. I
suppose I'm just making the more general point that forwarding isn't
required to have action-processing and view-rendering be decoupled. Perhaps
Struts should allow for that. Or perhaps Struts would rather put a stake in
the ground that forwarding is the preferred mechanism for invoking
view-rendering (and I can see the case for that, too).
Take care,
Donnie
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
