Yes, to Struts input is one thing, and output is another. Input has to
be coupled to the limitations of HTTP, and the ActionForms are designed
to cope with those limitations. On the other hand, most output needs can
be handled by returning ordinary strings, so Struts doesn't specify an
output bean. Any helper will do ;-)
Struts encourages good design -- but does not enforce it. Personally, I
would recommend that flow always pass through an Action before going to
a JSP. But if another developer feels differently, they can link
directly to the JSP. If the JSP has a html:form tag, then a default
ActionForm bean will be created, and any html form controls will be
populated to default values. But that's really a "completeness" feature.
It's important to realize that the framework does not expect that
ActionForm beans will be used for general output. ActionForm beans ~are~
expected to capture input, but all other bean strategies left to the
developer. If someone wants to reuse ActionForm beans for output, they
can, but this is not something the framework expects. Personally, for
most output needs, I would recommend using a standard "helper" beans,
which just return plain strings, and can be used in other environments.
To populate ActionForm beans for updates, I've been implementing an
interface over the ActionForm beans that uses a standard hashmap method
for bulk transfer. This way, the rest of my objects don't need to know
anything about Struts. Though, I'd like to try something with reflection
here instead.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
"Burleson, Thomas" wrote:
>
> Good point. And default/auto construction issue illuminates a design concern.
>
> Currently -- as I understand it -- the ActionForm (bean) is populated by the
>ActionServlet using introspection. And the Bean is then used by the Action (handler)
>to modify/update the business
> layer or model data. Then the actionForward is used to indicate which JSP the
>Servlet should forward/dispatch to. The page (which could be a different JSP page or
>the same used for the request) then searches for the ActionForm (bean) and creates
>one if it does not exist in the request scope.
>
> So (finally) here is the issue:
> The controller and handler uses a "dumb" bean to modify the model (MVC). Cool!
> But to gather information for use on a JSP, the bean must know how to gather that
>data from
> the business layer (model). BAD!!
>
> The handler should configure the bean BEFORE dispatching to the JSP. This way, the
>bean remains
> "dumb" and the handler centralizes all knowledge of the business layer.
>
> Struts seems to use 2 different patterns/approaches: the incoming processing is very
>different than the processing used during display of the JSP.
>
> Is my understanding correct?
