You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/06/23 13:08:19 UTC
Turbine & Velocity
[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
hps@intermeta.de +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: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Turbine & Velocity
Posted by Jonathan Revusky <jo...@revusky.com>.
Henning P. Schmiedehausen wrote:
> [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:
You are referring to this as FUD and implying an intent to deceive. That
is simply not the case. I don't know what you think this is. Do you
really believe that I would check out the code and make these comments
in an attempt to "spread FUD"?
What on earth would my motive be?
>
> % 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
I did:
grep -l "import org\.apache\velocity\." $(find . -name *.java")
and I got:
./org/apache/turbine/util/velocity/VelocityEmail.java
./org/apache/turbine/util/velocity/VelocityHtmlEmail.java
./org/apache/turbine/util/velocity/VelocityActionEvent.java
./org/apache/turbine/modules/pages/VelocityPage.java
./org/apache/turbine/modules/layouts/VelocityOnlyLayout.java
./org/apache/turbine/modules/layouts/VelocityDirectLayout.java
./org/apache/turbine/modules/layouts/VelocityXslLayout.java
./org/apache/turbine/modules/layouts/VelocityECSLayout.java
./org/apache/turbine/modules/screens/VelocitySecureScreen.java
./org/apache/turbine/modules/screens/VelocityDirectScreen.java
./org/apache/turbine/modules/screens/VelocityErrorScreen.java
./org/apache/turbine/modules/screens/VelocityScreen.java
./org/apache/turbine/modules/navigations/VelocityNavigation.java
./org/apache/turbine/modules/actions/VelocityAction.java
./org/apache/turbine/modules/actions/VelocitySecureAction.java
./org/apache/turbine/services/pull/TurbinePullService.java
./org/apache/turbine/services/pull/TurbinePull.java
./org/apache/turbine/services/pull/PullService.java
./org/apache/turbine/services/velocity/TurbineVelocity.java
./org/apache/turbine/services/velocity/VelocityService.java
./org/apache/turbine/services/velocity/TurbineVelocityService.java
That's 21 files. It's an awful lot of files to look at and figure out
where they fit into the picture.
>
> This is Part of the Turbine internal view. These classes were and are
> intented to be Velocity specific.
That much I know and don't dispute. OTOH I say there are too many of
them. I say that there should be only a handful, maybe 3 or 4.
> 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.
:-)
You think I didn't figure that one out, eh?
> The ..mail classes are used to generate mails
> from templates.
That stands to reason.
>
> 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.
Henning, in terms of implementing a FreeMarkerTurbineService or
whatever, there should be absolutely no onus on me to have this kind of
global understanding of the Turbine source code. Do you understand the
concept of a modular, componentized architecture? If this were properly
done, I would simply have one or two clear subclassing points and a well
documented contract to implement and that's that. It would just work.
>
> 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".
Well, then, Henning, does this kind of noise, like "Submit a patch"
actually make any sense???? Obviously, the code is not in a state that
you could seriously propose this!
In terms of wrapping up FM or another template engine so that Turbine
can use it, there *should* be no need to understand all of these things.
That is specifically the problem.
>
> 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".
Well, the untrained eye is what is important in this instance. You
shouldn't need to be knowledgeable about Turbine internals to do this.
> Fact
> is, that the Velocity <-> Turbine interaction isn't really 'visible'
> by doing a grep but by understanding the implications of our Service
> interactions.
There should be no onus on me or someone in my position to understand
all that.
>
> 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.
That I figured out.
>
> As I said before, supporting any other template engine takes time and
> work.
Right. It's too much work because of suboptimal design.
> 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.
The Niggle framework really includes the OREO classes as well, that I
have meant to break off as a separate library. That's org.oreodata.* and
that's more like 100 classes.
In any case, Niggle is still much more skeletal than Turbine, but I am
quite satisfied that it could be fleshed out to an arbitrary degree,
even bloated to the extent of something like Turbine, and no need would
arise for more points of coupling with classes in those template engine
libraries.
The reason is simply that, from the POV of a framework or app that uses
one of these template engines, usage always follows the same fundamental
pattern. You get vended the template, you stick some data in a
hashtable, and you merge the two things. That's it. It is quite easy to
generalize this pattern and thus, there is simply no valid reason for an
MVC framework (whether more bare-bones or not) to be referencing the
classes in org.apache.velocity.* in 21 different places.
>
> Doing a "quick check out" and then a grep over the code won't do.
It was sufficient with JPublish. The points of coupling with Velocity
were in 3 or 4 classes.
This is what happens when you do a similar grep over the jpublish sources:
grep -l "import org\.apache\.velocity" $(find . -name "*.java")
./org/jpublish/view/velocity/JPublishResourceLoader.java
./org/jpublish/view/velocity/VelocityViewRenderer.java
./org/jpublish/view/velocity/VelocityViewContext.java
and now for FreeMarker:
grep -l "import freemarker\." $(find . -name "*.java")
./org/jpublish/view/freemarker/FreeMarkerViewRenderer.java
./org/jpublish/view/freemarker/FreeMarkerViewContext.java
./org/jpublish/view/freemarker/JPublishTemplateLoader.java
It stands to reason that if I wanted to implement support for the
fictitious FooBar template engine, I would implement:
org/jpublish/view/foobar/FooBarViewRenderer.java
org/jpublish/view/foobar/FooBarViewContext.java
org/jpublish/view/freemarker/FooBarTemplateLoader (or
FooBarResourceLoader or whatever)
And I could look at the other implementations to use as a basis. There
would be no need for me to understand the entire JPublish architecture.
The reason is because this is architected correctly.
If I check out the code and do a grep and get the above result and it's
easy for me to add support for my component, I might well do it. In
fact, my offer stands. If you bring sanity into the situation, if you
get the coupling down to a few classes, I'll implement the FM service.
>
> 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. ;-)
At times, over the last few days, I have wondered whether I have been
oversensitized and overreacted to you and maybe some other people. I
don't really think so now. This latest thing takes the cake. I mean, the
very idea that I would check out the code from CVS and make these
comments on it solely in an effort to "spread FUD". Look, I have a real
hacker ethos. If I check out the code, and make some comments on it, you
can assume that I am making the comments in good faith. You really can.
I might say some things that are mistaken, sure, anybody can, but I make
whatever comments about code in good faith. It is one thing to think
that I'm abrasive (I certainly can be, especially when I feel people are
jerking me around) but in terms of commenting on code like that, that's
kind of sacred.
My earlier statements that honesty is absolutely necessary in a
technical endeavor stand completely. I really really believe that.
Now, as for the grep there and coming up with 21 files, that could be a
crude code metric. Probably is. But most code metrics are crude. It
still says something. 21 is a lot more than 3.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
>
> Regards
> Henning Schmiedehausen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org