Daniel Rall <[EMAIL PROTECTED]> writes:
>How about "death to bloat! Live long and streamline!"
>What color is your soapbox today? (Mine is tan. =)
Daniel,
this discussion finally died down on velocity-dev, it would be
great if we don't continue it here on turbine-dev.
What Mr. Revusky does not understand (because he has his hands over
his ears and screams at the top of his lungs, that "you must bring
your house in order" and "you have 21 coupling points to velocity in
turbine"), that actually Turbine has _one_ coupling point (the rest
are velocity related classes which can be replaced in a breeze with
"xxx-templating engine" related classes), which is unfortunately
embedded deep in another service (not templating related): the Pull
Service. Changing this (by either using a Map-based interface or an
adapter class) would mean an user visible break which according to the
deprecation rules must be pulled over one full release cycle. Actually
fixing the code is a matter of some minutes.
The Turbine-3 code base got this right, which is a result of the
pipeline and the decoupling of Fulcrum. However, this doesn't mean,
that Turbine-2 can't stea^Wlearn from it. ;-)
This is the same thing as with SecurityService and Torque. The
SecurityService has a org.apache.torque.Criteria object embedded in
its interface. This makes it very hard to write a non-torque-dependent
Security Service implementation.
The problem for some people is, that our two main view types of
interest (Velocity and JSP) are already supported by Turbine-2 and
there is no real pressure besides from "special interest groups" to
get another view logic.
Working on the pull service is one of the things for post-2.3 to
me. I'm pretty sure that what will materialize will be able to work
well with all kinds of templating solutions. Getting the Template
Service to work with Factories (which are currently wrapped a little
cumbersome into JspService and VelocityService) is an easy thing and
after some Avalonziation I'm pretty sure that Turbine will have a View
engine which is much superior to our current code.
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]
