Donnie Hale wrote:
> <Donnie comment>
> I understand that sentiment and, in general, agree with it. I just don't
> think the underlying premise of "servlet = controller only" or "servlet =
> view only" is necessarily valid. I think it's possible to have the
> controller and view be decoupled but still run in the same servlet.
> </Donnie comment>
Yes, via a VelocityAction that would do what Geir started to do with
VelServlet.
In Core J233 Pattern terms, Struts implements a "Service to Worker"
design pattern that combines a Front Controller with a dispatcher and
the View Helper pattern. In other words, the requests go first to a
central controller, then to a dispatcher, and finally to a third
component to render the view. In this context, the Struts Action classes
are the dispatchers.
Typically, the View Helper is another servlet, but there's no reason why
it couldn't be another Action. (After all, the dispatchers are typically
servlets too.)
I would just avoid a situation where developers needed to extend
VelocityAction to use the templates. Ideally, they should be able to
forward to a base VelocityAction from an existing Struts Action with no
other code changes. If someone wants to avoid another forward, then
perhaps they could extend VelocityAction and make it an all in one.
I also just suggested an InvokeAction method that could be used from one
Struts Action to directly call another, like a VelocityAction for
example. I later realized that anyone using may also need to cobble up
an ActionForm, so we'd probably need two companion methods (if we wanted
to allow this behaviour).
These compile, but haven't been tested:
public ActionForm createActionForm(String path) {
ActionMapping mapping = findMapping(path);
String name = mapping.getName();
ActionForm form = null;
ActionFormBean formBean = findFormBean(name);
if (formBean != null) {
String className = null;
className = formBean.getType();
try {
Class clazz = Class.forName(className);
form = (ActionForm) clazz.newInstance();
} catch (Throwable t) {
form = null;
}
}
return form;
}
protected ActionForward invokeAction(
String path,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
ActionMapping mapping =
processMapping(path,request);
Action action =
processActionCreate(mapping,request);
ActionForward forward = processActionPerform(
action,mapping,form,request,response);
return forward;
}
So in an Action, you could call
ActionForm secondForm =
servlet.createActionForm("/item/Edit");
ActionForward forward =
servlet.invokeAction("/item/Edit",secondForm,request,response);
> <Donnie comment>
> I agree with that to the extent that the view will be in another servlet,
> which means in the vast majority of cases. My primary concern with overuse
> of the contexts is in things not directly related to the request / session
> itself.
> </Donnie comment>
Struts is playing well others and making available resources that
someone else might want to use. Since things like the DataSource and
MessageResources are exposed in the application context, other
components can use them, even if the ActionServlet doesn't handle the
forwarding itself, and is not part of the instant request/response
cycle. An underlying idea is that while the ActionServlet may be loading
these resources, it doesn't "own" them, they belong to the application.
The contexts are provided for inter-component communication, and, IMHO,
are being used correctly.
Along the way, we have found a number of resources that we would like to
share among components, and a coherent API to organize the resources is
over due. A way for multiple ActionServlets to share their resources
with the application is also going to be needed. The API would still be
exposed through the contexts, though.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
