Jim Seach <[EMAIL PROTECTED]> writes:
Hi,
>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.
IMHO, no. Mainly because (as far as I understand the function of
VelocityServlet), this is already part of the Turbine Servlet (which
is, in fact, one big servlet. ;-) ). I haven't heard of
VelocityViewServlet, where can I find this?
We use our java-class broker to return render classes for "now take
this file and render it as <xxx>-template". This maps your template
name to a java class name. Most of the time, it comes out as "use the
VelocityPage class to render this template". Because the
VelocityService (see below) has registered the VelocityPage class as
the page render class for templates, ending in .vm
VelocityPage is coupling point between the class-based assembler
broker (in the AssemblerBroker Service) and the actual template
mapping engine (which came later into play when Turbine was already
busily serving web applications with a java based view).
VelocityPage prepares the Context by pulling it from the
VelocityService (which is the Factory that builds up and tears down
the Context objects and is also the initialization point for the
Velocity View engine) and then maps your template to an actual
template file (this is scope of the TemplateService), renders it (by
using Screen, Layout and optional Navigation) and returns it to the
container.
About supporting other templating engines on "equal footing": This
makes two assumptions:
a) The current code surrounding the view engine is abstract enough to
be templating engine neutral.
b) There is interest enough interest from Turbine developers to support
a second, third, fourth, fifth engine.
For a): Most of the code is. Some is not. This will change post-2.3
For b): There are much more interesting fish to fry and code to
write. At least I have no intention to do so in my _spare_ time.
Personally I have a templating engine that fills all my needs and I
see no reason to reinvent the wheel. If a developer or a project
needs an <xxx>-view, well, they can communicate with the Turbine
developers to donate code (that is what open source is all about)
or they can contract one of us to write it for them.
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]
