[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
