> You should note, however, that it is also possible for an Action to create
> the view directly, if you want to:
>
> public ActionForward perform(...) ... {
>
> ...
> PrintWriter writer = response.getWriter();
> writer.println(...);
> ...
> return (null);
>
> }
>
> Returning null, instead of an ActionForward instance, tells the controller
> servlet that the response has already been created. Of course, you could
> do other things (like call a Velocity template) instead of writing the
> response directly, as well.
>
> Thus, anything for rendering the view layer that is accessible only
> through API calls is also usable in Struts.
...
> Craig
I know, I know. But: do you want to rewrite your action e.g. just because
X team decides to change the view presentation mechanism? Clearly not.
You really want that the action update the model and then depending on
the result of the update operation and the current running context give
back and abstract view to be presented.
E.g. you have some form to add a customer to your customer base. After
the action you want to present the list of your customers. Up until
now, you've used jdbc/jsp. Now your collegue decides to kepp the customers
in XML file. The cheapest way now is to give the file to an xsl sheet
to render. But the action should remain the same: update the customer list
and give back that you'd like to render the table of current customers.
Currently, in this situation you have to change your original action and
writing the new rendering. If the actionservlet would use ActionForwards as
facades (the same way as with Action itself) you have to write only the
new rendering. If these renderings were general enough to be configurable
by struts config - then you have to write nothing, just change the
configuration. I think that's all what I was speaking about (and if
I did not misunderstood him, Donnie Hall). It's only seems to me that
this way it is easier to attach configurable view mechanisms to the
framework and the coupling between the controler servlet, the user actions,
and the rendering mechanisms would become minimal.
That was the one side of the coin. The other is the dispatcher mechanism.
It was only a _question_, I am really wonder, why does it count to be
the standard, that you give the rendering to a different SERVLET.
Is there any advantage (e.g. in the above example using an XSL servlet
and forward to it)?
incze
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
