Would it make any sense to support view/template engines by forwarding
to a view-specific servlet (like the newly released
VelocityViewServlet) and communicating with all view engines through
request, session, and application attributes?  That way you let the
Servlet mapping function of the Servlet container choose the view
engine and they would all be on the same footing.  It would be the
responsibility of the view engine's servlet to make the Turbine objects
available to the engine in the proper manner.

(I haven't used Turbine yet, so please forgive me if this is totally
off-base :^)

Jim Seach

--- "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote:
> Jonathan Revusky <[EMAIL PROTECTED]> writes:
> 
> >Yeah, I know it's pretty trivial really. But, then the other classes
> >should really use the template service abstraction. You shouldn't
> have
> 
> You don't understand what the template service does. You read
> "template" and think "template engine". That's your problem. You talk
> before you think.
> 
> TemplateService is a vastly different beast than "maybe similar named
> things in other frameworks". What you think of are Template Engines,
> which are in Turbine _completely_ separated out into things like
> JspService and VelocityService and register with the TemplateService.
> 
> Turbine can use multiple templating engines simultanously. We can
> have
> JSPs and Templates side by side in a single application.
> 
> Template Service is mapping template descriptors (like
> "foo,bar,Baz.vm" 
> or "yadda,yadda,Yadda.jsp" to a Templating Engine (Velocity or JSP or
> anything else) and let the templating engine render it. It is
> _completely_ engine independent. In fact it couldn't care less what
> engine is used to _render_ a template.
> 
> You won't find a single reference to any templating engine in the
> o.a.turbine.services.template package (besides examples used in the
> comments).
> 
> >all these other things that directly use velocity classes. It makes
> no
> >sense.
> 
> It makes no sense to you. Because you don't understand the basic
> concepts how Turbine pages are rendered from page, layout and screen
> classes. This is classes. Not templates.
> 
> And I do not feel inclined to describe it to you, because you won't
> listen anyway. If you dig in the turbine-users archives, you can find
> a long mail from me where I describe the process (including the
> AssemberBroker and Template Service lookups) in detail.
> 
> You're looking at the wrong place. Supporting any other templating
> solution in Turbine is ridiculously easy. That's why we hade at some
> point five of them (Vel, JSP, FM, WM and Jython).
> 
> But getting the stuff where Turbine _really_ shines and is superior
> to
> other web frameworks, which is the whole tool mechanism from the pull
> service and the toolbox, is hard. Because the original _Pull_ Service
> was written with Velocity in mind. And this is where the problem
> comes
> from. And this is, why Velocity was always better supported than any
> other templating solution. And this is, why no one bothered to use FM
> and WebMacro with Turbine. And this is, why at some point, the
> support
> for these rotted and was dropped.
> 
> I've told this numerous times but you neither listen (hands over your
> ears) nor do you accept it as the truth, but you prefer to believe in
> some obscure Apache conspiracy theory. So be it, I accepted it.
> 
>       Regards
>               Henning 
> 
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> [EMAIL PROTECTED]        +49 9131 50 654 0   http://www.intermeta.de/
> 
> Java, perl, Solaris, Linux, xSP Consulting, Web Services 
> freelance consultant -- Jakarta Turbine Development  -- hero for hire
> 
> --- Quote of the week: "It is pointless to tell people anything when
> you know that they won't process the message." --- Jonathan Revusky
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Reply via email to