Jonathan Revusky <[EMAIL PROTECTED]> writes:
Henning P. Schmiedehausen wrote:
[...]
No, we didn't. You're right. All of the active developers that I know
use Velocity in their projects and at least I don't see much sense in
supporting something that is not in demand by our users (on
turbine-user)
Well, frankly, I don't see much sense in putting a note on top of the FreeMarker bridge classes that says "Deprecated. Use Velocity instead." and then saying stuff like "FM support was removed because nobody was using it" or (stated in an innocent tone) "There does not seem to be any end-user demand for this" and neglecting to mention that you specifically told people not to use it!
Look,
you seem to try very hard to turn words in my mouth.
Henning, could you provide a concrete example of my "putting words in your mouth"? I am certainly not aware of it. I have simply responded to the things you have actually said. And I have read your messages quite carefully, even multiple times, to make sure that I understand what you are saying. So, if I have misinterpreted anything that you have said, that may be your fault, for not expressing yourself clearly enough.
Also, my perception that much of your discourse is self-contradictory, and seems to be deliberately deceitful, is not mine alone. I have had some private dialogue where other people have expressed the same view.
For starters, this whole business that you removed FM support because there was no end-user demand is clearly based on a big "beg-the-question" fallacy. Obviously nobody was going to use FM or WebMacro in conjunction with Turbine if the actual developers put a note on top of the relevant classes telling people specifically not to do that. Even if there was some period before that where that note was not explicitly there, the fact that the usage of FM was de-facto not supported was pretty clear simply by the fact that it only worked with a 3-year-old version of FM.
Really, you could *only* state good faith way that there was no end-user demand if the tools were presented and maintained on an equal footing and people were simply left to make their choice. However, that was never the case. And, once you, the developers, specifically tell people to use Velocity and discourage them from using FM or Webmacro, obviously, people obviously aren't going to use those things.
To then say, "Oh gee, there was no end-user demand" is very hard for me to interpret generously.
Fact is, that this was (and is) the timeline:
I'm going to snip your timeline because I find it uninteresting. It seems like just more of this same "beg-the-question" stuff.
End of story. No conspiracy here. Nevertheless I personally feeling that my opinion is starting to move from "being totally indifferent to FM, because I don't use it" towards "Uh, those guys have a serious ego problem".
Well, in terms of having "we are the world" kinds of delusions, I don't think that jakarta developers are in much of a position to start calling the kettle black.
The fact remains that my perception is that FM support was removed from Turbine for entirely murky, non-technical reasons. Now independently of whether my view is correct, given that this is my view, is it really very likely that I am going to invest any of my own energy into helping you put the FM support back in there?
Obviously, my position is: "You guys removed it, you guys put it back." Would that not be the position of just about anybody in my shoes?
How would you yourself react if roles were reversed?
And especially, when the value-added is almost entirely on the Turbine side. We gain fairly little, after all.
Henning, you have heard of the "beg-the-question" fallacy, haven't you? Aren't you engaging in a version of that?
and not used by the developers (on turbine-dev).
Well, given that there is significant overlap between the core Turbine team and the original Velocity developers, it does not surprise me that they favor Velocity.
You may look up who did commits to the Turbine code in the last six
months. I'd guess that you won't see any "original Velocity
developers".
You have the advantage over me on that. I do not follow what is happening in Turbine development. Now that you mention it, what you say is not surprising. The original Velocity developers have abandoned Velocity development. That they also have abandoned Turbine development would not be surprising. They have every right to do that, of course. I just mean that if they abandoned the one thing, sure, it makes sense that they abandoned the other thing in the same approximate space.
But it's irrelevant really. I mean, the Turbine developers (whoever they were) removed FM for whatever reasons. And if the current Turbine developers (whoever they are) want to put it back, they should do so themselves.
Patches are (as always) welcome. If you have a working FreeMarker templating solution (which shouldn't be too hard to do) for Turbine, we will put it into the CVS tree in a second. But please don't think that any of the active developers will spend time that is better spent on things that we _know_ that they're used than on supporting "yet another templating solution".
<sigh>
I don't know what this thing about "yet another" templating solution is. As far as I can tell, the only templating solution you support currently is Velocity. Wouldn't anyone reading this "yet another" infer that you were already supporting several of them?
We have one that seems to work for everybody that uses Turbine. That's seems to be enough. As you yourself said: If it's so simple to support FM in Turbine, why hasn't anyone posted a patch which allows FM 2.x as View of Turbine? Answer: There seems to be no demand.
Well, if you guys explicitly supported FM before and then chose to remove it, people who know that are not so likely to bother to submit a patch for you to put it back in, are they?
But, in general, I read your messages and I have a hard time processing what you're saying. There seems to be unresolved subtext. You have expressed an interest in having a template-engine-neutral architecture. That would imply that you consider it desirable to support more than one template engine. If you do want to support another template engine besides Velocity, and that other template engine is not FM, which one(s) were you looking at?
Everyone that we get patches for. But we don't run around looking for code to bolt onto Turbine unless there is demand.
Well, already, I don't quite understand your message. Why bother with a template-engine-neutral architecture if only supporting Velocity is good enough?
Asides from being able to juggle with floats on a template, having a
few more control statements (such as being able to break out of a
loop) and name space support (which is nice and I'd really like to
have that in a view), I don't see too many differences between
Velocity and FM.
Well, I guess you didn't look very carefully. I gave you a list (on your request) that included significantly more checkpoints than what you have stated above.
I saw your list after this post. It still holds true to me. Anything
else you support is either eye-candy or simply not part of the View
scope.
OKay, let's take an example. FreeMarker provides the ability to apply escaping on blocks of output.
<#escape x as x?html>
${foo} etcetera
</#escape>Within the above block, all variable interpolations are HTML-escaped. So, the ${foo} actually becomes ${foo?html} which means that any '<' character in foo is turned into $lt; and so on.
This was one of the things FM has that Vel lacks that you failed to mention. Is it eye-candy? Is it not part of the view scope?
What about the ability to expose time/date objects and have them transparently formatted according to the template's locale? Is that not part of the scope of a view component?
I pointed you to a fairly comprehensive list of things that FM has and Vel lacks, and most of them are *clearly* useful and appropriate within the scope of a view component.
From your statements above, I do not get the impression that you really looked at the material or links I provided. I know you're probably a busy guy, but hey, If I take the bother to provide you information that you have specifically requested, you really ought to look at it. But if you don't, at least you should not represent that you have done so.
> Yes, these are nice features and maybe my position is "too
purist". But then again, I personally don't care much (I have other work to do) and if someone needs FM support, he should donate a patch.
In any case, it goes beyond a list of checkpoints like that. The fact remains that, at this stage of history, FreeMarker is actively developed and maintained and Velocity is not.
So what? When the available tools fulfil the needs of 100% of the
users,
Henning, you don't know that. I run a couple of open-source projects and I know full well that only a very small percentage of users actually give you any feedback.
The statement that you know you are fulfilling the needs of 100% of users is already quite ludicrous. But to make matters worse, it's also clearly based on fallacious reasoning. It's like saying that a restaurant should not add Hungarian ghoulash to the menu because the current clientele is completely satisfied with the current menu -- which does not include ghoulash.
Well, of course, the current clientele is largely satisfied with the menu. That's why they're the current clientele. If they weren't satisfied, they would stop going to your restaurant. OTOH, you don't easily know how many people had a craving for Hungarian ghoulash and simply never entered your restaurant because you didn't have it on the menu.
And, of course, an OSS project is in far worse shape than a restaurant in this regard. A restaurant has much better contact with its customers, and can view their reactions and whether they leave food on their plate, and can see who looks at the menu in the window and then walks away. In an open-source project, you are largely operating in a void of such information. You have no notion of how many people visit your webpages and/or download the distro and then decide against using your software because it lacks features they want or need.
So your stated conviction that there is no demand for this is highly suspect.
there is no point in supporting another tool which will not be used.
<sigh>
I have no further comment on that.
[... pointless rant read and deleted ...]
Well, yeah, that was the part where I pointed out that Velocity is no longer actively developed or maintained, and, by only supporting that as your view component, you were damaging your own project.
That was the "pointless" rant that you snipped.
I agree to disagree with you. I'm pretty sure that at some point a developer will want to have FM support in Turbine or Turbine support in FM and then send in a patch for make it possible.
They might, but it's out of my hands. You can support FreeMarker if you wish, but at this stage, with the water that's gone under the bridge, to solicit my help is really quite ludicrous.
Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html FreeMarker 2.3pre4 is out!
Regards Henning
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
