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"),
Henning, I do think you're trying to bait me. Finally, I'm replying nonethless, but simply to address quite calmly the points that I think need to be addressed.
First of all, I am not screaming that "you must bring house in order". Far be it from me to "demand" that you do anything with *your* project. I am simply stating that if you do not get this situation into better shape, you cannot expect any help from me in terms of any FreeMarker integration, and it is unreasonable to solicit any help from me, along the lines of "Submit a patch" and so on.
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.
Yeah, I know it's pretty trivial really. But, then the other classes should really use the template service abstraction. You shouldn't have all these other things that directly use velocity classes. It makes no sense.
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.
Look, this is a very clear attempt to spin the situation. First of all, the question was posed on the turbine-user list and various people expressed interest in FreeMarker support. IIRC, at least three people openly said they would give FM a try if it was available within Turbine. Now, that may not sound like a lot of people the fact remains that, in open-source projects, one tends to get fairly little feedback. If several people openly say they are interested in something, it is safe to assume that there are far more people who would be interested that you don't know about. Certainly, I thought the response was favorable enough that, in your shoes, I would assume there was significant interest in FreeMarker -- and possibly other alternatives to Velocity. Moreover, I do tend to think that the tight coupling with Velocity, at the moment, makes Turbine less attractive to potential users than it would be if the framework were truly view-tool-neutral.
In any case, when I say that you are putting "spin" on the situation, it is not just the above. You see, basically, on first principles, there is no particular reason to consider that FreeMarker integration is actually more of a "special interest" than Velocity integration. That Velocity was set up as the default, and other tools were never really equal citizens, as it were, that's basically an artificial situation entirely of the making of the Turbine developers. And, as far as I can see, it is not something technically based really.
Again, it strikes me as quite dishonest, Henning, to keep on with variants of this: "Nobody or hardly anybody is interested in FreeMarker integration" -- when all of your evidence in this regard is based on a completely rigged comparison, where FreeMarker support in the past only supported an extremely obsolete version, and obviously nobody was going to be interested in it. And besides that, the recent evidence (based on actually asking people on the turbine-user list) is that there is significant interest in FM support.
Actually, I am quite convinced that, once you offer Velocity and FreeMarker support on an equal footing, your user base (particularly new users) will tend to gravitate towards FreeMarker, simply because it is much more powerful and is being actively developed and maintained.
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.
Well, my offer stands. If you get rid of all these points of coupling, I'll help you within the boundaries of the reasonable. But without that, it is simply not a reasonable situation, you see. If there are all kinds of helper classes in the framework that only work with Velocity, then FM is not competing on an equal footing, since there is functionality available via Velocity that is not available to the user who opts for FreeMarker.
What this means is that the overall Turbine codebase should not use Velocity classes directly, but rather, the abstracted TemplateEngine API that potentially encapasulates Velocity, FreeMarker, and other tools.
Anyway, I never demanded or screamed that you had to do anything. I simply stated the conditions under which it would make sense for me to help you on this front. I further said that if you got rid of all these points of coupling with Velocity classes, I would do my part to get the FM integration working. Now, I do wish you would stop playing games and attempting to spin and distort everything that is going on, and portray me as some kind of lunatic. I am satisfied that anybody who reflects seriously on what I am saying will realize that my position is emininently sane and reasonable.
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html
Regards Henning
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
