Jonathan Revusky <[EMAIL PROTECTED]> writes:
Yeah, I know it's pretty trivial really. But, then the other classes should really use the template service abstraction. You shouldn't have
You don't understand what the template service does. You read "template" and think "template engine". That's your problem. You talk before you think.
<sigh>
Look, all this baiting and so on, it's a little bit too obvious. My read on this is that you want me to get angry. It gives you something tangible to sink your teeth into, and then then all the other yahoos can pile on.... that much is clear, but I am wondering about the motive. I guess the motive is sort of tactical, to create a distraction or something.
I could be wrong, but that's my understanding of this.
I mean, I look at this situation and I see the following points:
1. It's pretty trivially simple for anybody who actually knows the Turbine code (you, for example, *not* me) to refactor things such that multiple template engines can be supported on an equal footing. You could fix this today if you wanted to.
2. Not only is such a refactoring clearly desirable for its own sake, but, when asked, some users expressed quite real interest in giving FM a try. I have little doubt that a lot of people are up to the gills with some of Velocity's limitations and the lack of any forward movement in that camp.
So clearly, you should do this. However, I guess you don't really want to do this (probably, for whatever murky non-technical reasons... if I state them, you'll start with this "conspiracy theory" stuff again, so I won't...).
So, bottom line: you're trying to create a distraction.
TemplateService is a vastly different beast than "maybe similar named things in other frameworks". What you think of are Template Engines, which are in Turbine _completely_ separated out into things like JspService and VelocityService and register with the TemplateService.
Turbine can use multiple templating engines simultanously. We can have JSPs and Templates side by side in a single application.
Template Service is mapping template descriptors (like "foo,bar,Baz.vm" or "yadda,yadda,Yadda.jsp" to a Templating Engine (Velocity or JSP or
anything else) and let the templating engine render it. It is
_completely_ engine independent. In fact it couldn't care less what
engine is used to _render_ a template.
You won't find a single reference to any templating engine in the o.a.turbine.services.template package (besides examples used in the comments).
Well, I'm sure that's all true, but the fact remains that I don't know which package does what and there is not much onus on me to know these things. Also, these things aren't terribly well documented anyway.
All I know is that I finally did a CVS checkout to evaluate how difficult it was to put FM support back, and, with a quick grep, I saw that Velocity API's are used directly in a lot of different places throughout the code. I counted 21 different classes.
I have a lot of different things I'm doing, I didn't consider the situation reasonable, so after taking that glance, I simply gave up on it. I wrote a note in which I said that this was the situation and that it wasn't reasonable. In response, you accused me of spreading FUD.
But anyway, it seemed to me that you did not have a sufficiently modularized codebase that I could offer a patch. Now, this was after you (and someone else IIRC) started this "submit a patch" sort of stuff. I concluded that the "Why don't you submit a patch" stuff was not stated in good faith, because you knew perfectly well that the codebase was not in a state that I could just go in and find a couple of key points to patch.
This is confusing stuff. My current interpretation of this weird behavior on your part is that it was political in origin. You wanted to spin things in such a way that the lack of support for FM, say, was due to something that *I* wasn't doing. You were trying to represent that there was some onus on me to just submit a patch. My pointing out the 21 coupling points made it pretty clear that there was no such onus on me, that the ball was in your court.
I earlier stated that I was unwilling to do anything on this because of the history of this whole thing. However, I changed my position. My position is now, that if you get your house in order on all these various points of coupling with org.apache.velocity.* classes in the codebase -- so that the codebase generally just uses whatever template engine abstraction you set up, then I would help you.
The offer of help is sincere and I stand by it, but to be completely frank, it was offered for tactical reasons in a sense. I simply did not want you to have any excuses.
all these other things that directly use velocity classes. It makes no sense.
It makes no sense to you. Because you don't understand the basic concepts how Turbine pages are rendered from page, layout and screen classes. This is classes. Not templates.
Well, there is no onus on me to understand these things.
And I do not feel inclined to describe it to you, because you won't
listen anyway.
This is more baiting, but you actually have a point. I have little time for listening to you explain all this stuff. It's of no interest to me. If you get the codebase to the point where you don't have all these coupling points with Velocity classes, where the framework just uses Vel through a generic template engine API, I will help you get FM working via the same generic template engine API. If this is done properly, I don't need to undersand how the Turbine framework works as a whole. I just implement the API's needed to plug in FM and that's that.
However, from my POV, if you don't get rid of all those coupling points, I would be wasting my time. You see, if I go through the bother of making FM available through some abstracted tempalte engine API, but large parts of your codebase use Velocity classes directly, then there will be significant functionality available to Velocity users that is not available to people who opt for FM.
Ergo, same rigged situation as before. Ergo, I'm wasting my time. And I don't like to waste my time.
If you dig in the turbine-users archives, you can find a long mail from me where I describe the process (including the AssemberBroker and Template Service lookups) in detail.
No onus on me to understand any of this really. At least, certainly, unless you get your house in order on all the points of coupling with Velocity classes, it is a waste of my time to bother with looking at this.
You're looking at the wrong place. Supporting any other templating solution in Turbine is ridiculously easy. That's why we hade at some point five of them (Vel, JSP, FM, WM and Jython).
Well, if it's that easy and you have such a wonderful architecture for supporting view tools, then why is it that the only template engine people can use through Turbine is Velocity?
Doesn't make sense to me...
But getting the stuff where Turbine _really_ shines and is superior to other web frameworks, which is the whole tool mechanism from the pull service and the toolbox, is hard. Because the original _Pull_ Service was written with Velocity in mind. And this is where the problem comes from. And this is, why Velocity was always better supported than any other templating solution. And this is, why no one bothered to use FM and WebMacro with Turbine. And this is, why at some point, the support for these rotted and was dropped.
I've told this numerous times but you neither listen (hands over your
ears) nor do you accept it as the truth, but you prefer to believe in
some obscure Apache conspiracy theory.
<sigh>
My belief that the decision to favor Velocity over other solutions was not entirely technically based is hardly that much of a conspiracy theory, Henning. This attempt to portray me as some kind of lunatic because I simply state things that everybody who wasn't born yesterday knows anyway... that's getting a bit old, isn't it?
Just one final question:
It's clear what needs to be done, right? Given that, do you have any intention of doing anything on this?
(Okay, that might be 2 questions, but they're reasonable questions, I think...)
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
So be it, I accepted it.
Regards
Henning
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
