[I swore to myself not to do this. If I get flak for it, well, ok. I
deserve it. ]
After the level of FUD in this group is continually rising and some of
the people came to the conclusion that Turbine is completely
"velocityized" by doing a simple grep, here are some facts:
% find ~/jakarta/jakarta-turbine-2/src/java -name \*.java -exec grep -iq 'import
org.apache.velocity' {} \; -a -print | less
java/org/apache/turbine/modules/actions/VelocityAction.java
java/org/apache/turbine/modules/actions/VelocitySecureAction.java
java/org/apache/turbine/modules/layouts/VelocityDirectLayout.java
java/org/apache/turbine/modules/layouts/VelocityECSLayout.java
java/org/apache/turbine/modules/layouts/VelocityOnlyLayout.java
java/org/apache/turbine/modules/layouts/VelocityXslLayout.java
java/org/apache/turbine/modules/navigations/VelocityNavigation.java
java/org/apache/turbine/modules/pages/VelocityPage.java
java/org/apache/turbine/modules/screens/VelocityDirectScreen.java
java/org/apache/turbine/modules/screens/VelocityErrorScreen.java
java/org/apache/turbine/modules/screens/VelocityScreen.java
java/org/apache/turbine/modules/screens/VelocitySecureScreen.java
This is Part of the Turbine internal view. These classes were and are
intented to be Velocity specific. Their superclass are the Template
counterparts like TemplateScreen. For any other templating solution,
the author would have to supply similar classes.
java/org/apache/turbine/services/velocity/TurbineVelocity.java
java/org/apache/turbine/services/velocity/TurbineVelocityService.java
java/org/apache/turbine/services/velocity/VelocityService.java
The turbine internal service that deals with creation and deletion of
the velocity objects. For any other templating solution, a similar
service would have to be written, which controls the View portion of
Turbine.
java/org/apache/turbine/util/velocity/VelocityActionEvent.java
java/org/apache/turbine/util/velocity/VelocityEmail.java
java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
Velocity specific helper classes which are intended by their authors
to work with velocity. The ..mail classes are used to generate mails
from templates.
java/org/apache/turbine/services/pull/TurbinePull.java
java/org/apache/turbine/services/pull/TurbinePullService.java
Implementation of the TurbinePull Service which provides us with Pull
tools in the view context.
java/org/apache/turbine/services/pull/PullService.java
And this is, where the problem lies. Anyone, who can actually
_understand_ the Turbine source code (and do more than a quick grep)
can see this.
By looking at the differences of JspService and VelocityService, this
might be even more clear.
Considering the fact that Turbine currently contains > 450 classes and
29 different services, I'd say that an intimate understanding of the
inner workings that is needed to be able to change the code in a way
that the user visible interfaces don't break left and right might take
quite some time. Maybe even "ages".
However, when comparing something as feature complete and containing a
large toolbox as turbine with a simple, skeletal web framework, this
might seem to the untrained eye as "having 21 coupling points". Fact
is, that the Velocity <-> Turbine interaction isn't really 'visible'
by doing a grep but by understanding the implications of our Service
interactions.
Turbine currently provides 13 helper classes for the Velocity View and
two more classes which use Velocity to do something else (sending out
mails from velocity templates). We never had as much support for any
other templating solutions. The functionality of each of these classes
can easily be provided for any other templating solution, if someone
would write them. But as it is, we have things like secure screens or
multiple layout providers only for Velocity.
As I said before, supporting any other template engine takes time and
work. Just writing some classes, that extend the abstract template
classes is simple and a work of hours. The net result would be exactly
the level of support that Turbine had for Jython, FreeMarker and
WebMacro as in 2.2. Which is seriously below the level of
Velocity. Doing so would not do a favour to these products. The fact
that in the whole 2.2 development cycle (which actually took ages),
not a single developer or user stepped up and added FM, WM and Jython
classes to the Turbine core might seem to the developers community
that noone is really using this. Which leads to code rot. Which led to
the removal of this code. End of story.
Judging by the fact that the often quoted Niggle framework has exactly
nineteen classes in the org.niggle... package might make it more
clear, that we're dealing with a bit more complexity here.
Doing a "quick check out" and then a grep over the code won't do.
Personally I'd recomment everyone using Turbine or developing on the
Turbine code base to simply ignore mails that obviously aren't
intended to help us. Unfortunately, I can't even convince myself to do
so all the time. ;-)
Regards
Henning Schmiedehausen
--
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]
