Incze Lajos wrote: > 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)?
The only real advantage is that it makes the rendering service available to environments other than Struts. When the ActionServlet dispatches the request to the Action, it also "deputizes" the object so that it can do whatever a servlet might usually do. For an example, an Action can + Create its own response to the request, + Access or create other objects in any scope, + Forward or include another servlet via a RequestDispatcher (witness ForwardAction and IncludeAction in the Actions package). And, if you really want to, you can even invoke another Action directly. So creating a XSL Action is definitely an option. But, the inverse is also true. Anything an Action can do, a servlet can do. So, why not keep the view decoupled from the Struts, and, at the same time, make it available to other environments? Struts offers some tag extensions, mostly because when we (meaning Craig) started, there was no Jakarta Taglibs or JSPTL, and developers were desperate for decent taglibs. So Mr. McClanahan kindly provided them ;-) But, the Struts framework is really about about the Controller. You can use Actions as View Helpers, but if these views were going to be the basis of *my* application, I'd put the rendering engine in its own servlet. -- 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]>
