No, the question is entirely independent from velocity. There are
many possibilities to render a view. E.g. Maverick "domifies" a data
structure and gives it to an XSL transformer, etc. What I was wonder
was simply the WRAPPING of the view helper. To me it seems to be
natural to hide (and make it configurable) the calling mechanism
of the view renderer. You can dispatch a servlet from a wrapper object
if yo want. What bothers me is that in ActionServlet a new servlet
dispath is wired. (I do understand that it can be a velocity servlet,
an xsl servlet etc.) The question is: why is the default to dispatch
a new servlet? What is my benefit over a simple call (that could dispatch
a new servlet if needed)?

 see that what you wrote ("Typically, the View Helper is another servlet...")
seems to be a commonplace somehow - but don't understand.

Anyway, don't bother with me, if that's the course, let be it the
course. Just wanted to learn something. Thanks

incze

On Mon, Dec 03, 2001 at 01:56:06PM -0500, Ted Husted wrote:
> If the one and only goal is getting Struts to use Velocity templates,
> then, yes, a VelocityAction is going work every bit as well as a
> VelocityServlet. And maybe that's the way to go. A developer could
> choose to either extend it, or maybe just forward to a base
> VelocityAction that did what the VelServlet is trying to do. Both
> approaches could probably be supported at once.
> 
> But, if it were me, I'd first think in terms of a VelocityServlet that
> is designed to answer from a URI, and create a chained VelocityContext
> from a request/session/application contexts. 
> 
> Then, I would subsubclass that into a VelocityActionServlet that knew
> about the Struts resources. (If that part were actually needed.)
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
> 
> 
....
> > > Typically, the View Helper is another servlet, but there's no reason why
....
> > >
> > 
> > I've never understood this claim. As I see a servlet is a processing unit
> > of an HTTP request/response turn. You want to isolate a servlet if the
> > iprocessing unit is directly callable from the HTTP connection. There is
> > no any other structural feature in the servlet over a simple subroutine call
> > to a view. Even you have to work some to put everything into the request
> > that could be available otherwise. I can't see any benefit in declaring
> > that the viewer helper is another servlet if it was not actvatable directly
> > from outside by an URL. Am I missing something?
> > 
> > incze

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to