Jonathan
Based on this:
Jonathan, some technical information (which you as a non-Turbine guy
might not have seen yet): Unfortunately the o.a.velocity.Context is
buried pretty deep in the Turbine code (this is legacy of the original
turbine developers). So we will have to replace this in every place
with an Adapter class with plugs either onto the Velocity Context or a
similar class in every other view solution (FreeMarker, WebMacro
etc.).
Doing so, it would be necessary for all of our users to change the imports in their self-written classes (Action, Screen), because the Context is part of the signature of the methods which are overloaded by user classes.
If we don't do this but just 'bolt FM support on' by using different classes, there wouldn't be much won, because people would still use VelocityScreen, VelocityPage etc. just as in all the example code around and the FM code would start to rot (again). I don't want this, because it wouldn't buy much for the Turbine users. So we would need some major core changes to allow developers to simply switch views without having to rewrite all of their classes later.
In addition, I based my point on the fact that the current developers obviously already made such a determination when they made the decision to stop supporting it.
Well, that just begs the question, doesn't it? That a decision was made in the past does not logically demonstrate that said decision was correct.
I maybe did not express my point clearly enough, if this is merely a
matter of adding Freemarker support for political reasons, its a waste
of time.
Look, you don't have to look very far for non-political reasons to support FreeMarker in addition to Velocity. For starters, FreeMarker is a much more powerful tool. I pointed to a list of features that bears this out. Not only that, but Velocity is basically a dead project. To all intents and purposes, nobody has committed any new code there for a year. Bug reports are ignored. Feature requests are dismissed with rather specious arguments. Anybody who realizes the state of that project could well be given pause by the fact that Turbine offers no alternative. At this stage, it is likely to cause you to lose potential users.
But, even besides all of that, it is simply better to offer a choice! Choice is clearly advantageous. I might always vote for the same political party but that does not mean that I am in favor of a one-party state!
Since choice is clearly beneficial and adds value, it is the *removal* of FreeMarker and Webmacro as options that seems easier to characterize as "political" than vice versa. Giving users *more* options tends to add value and there is no particular reason to infer political motivations.
Not just the developers, but all of ours. The simple fact is I do not remember any amount of clamor over the decision to withdraw support of FM and WM. When the decision was announced to the list, my stance was that having support for these technologies was good for Turbine but it didnt make sense if no one was using them. If there were enough users to justify the work, then I dont think that support would have been withdrawn.
Well, Henning also trotted out this thing about nobody using FreeMarker. I'm sure it's true, but OTOH, c'mon, it's really something of a half-truth.
You see, there was only support for a very obsolete version of FreeMarker, 1.5.2 IIRC. Nobody interested in using FreeMarker would gravitate towards a framework that only supported 1.5.2. As of this writing, the current stable version of FM is 2.2 and the development version is 2.3. So that means we've gone through a 2.0, a 2.1, and 2.2 release cycles. And take a look at all the features that have been added.
It's really like supporting the use of java, but by supporting JDK 1.0.2. Now, obviously, nobody uses that java support, because nobody interested in using Java wants to code to 1.0.2. They all want to use a more up-to-date version. Nonetheless, you say that nobody is using java, so obviously nobody is interested in Java.
By the same token, nobody interested in FreeMarker would gravitate towards a product that only supports FM 1.5.2.
Even aside from that, another obvious reason everybody would use Velocity is that it was set up as the default. Anybody who understands this industry understands the power of being the "default". This is the "secret" behind the success of Microsoft products. They are positioned as the default in their space.
And, of course, when you realize the positioning involved, where Velocity is a fellow Jakarta/Apache project...
To be able to say in a good-faithed manner that nobody was interested in FM and WM, you would have had to present the various solutions on at least somewhat equal footing and let people make their choice. I'm quite sure that never happened. You would have to be supporting up-to-date versions of the tools. So, what you're talking about is the result of a completely rigged experiment. "We gave people the option and nobody was interested".
C'mon, guys....
But that's all water under the bridge anyway. At this stage of history, certainly, given FreeMarker's current lead over Velocity technically, it is hard to imagine that the two could be offered on a reasonably equal footing and that everybody would opt for Velocity. Many people would compare and opt for FM.
If I understand the current path of Turbine, its continuing development
is targeted at eventually moving users to Avalon. I assume that as this
transition takes place, services will be built more view independent. So I dont think it makes a lot of sense to devote resources to reversing
the previous decision in the current Turbine code.
I am not a Velocity proponent, the decision to use Velocity was made before I came to this company. Velocity would not have been my choice.
All that being said, I have nothing against Freemarker, but I have no intention of supporting a decision to re-support a technology that doesnt seem to be used by the community, and will cause everyone in the community to perform a migration.
Well, I don't know all the internals of Turbine, and I don't really care to, but if you can't add FM support in such a way that it causes no inconvenience to existing users who want to continue with Vel, it just means that Turbine is rather poorly architected.
Now, as a final note, I have been reluctant to be in this conversation. I do not want to give the impression that I care very much whether Turbine supports FM or not. Because I don't. Still, I was curious what was going on with this discussion, and there were certain things said, arguments made, to which I could not help but reply, as I did above.
Best Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker-Velocity comparison page, http://freemarke.org/fmVsVel.html
Velocity->FreeMarker template conversion tool, http://freemarker.org/usCavalry.html
Just my $.02
On Wed, 2003-06-18 at 10:47, Jonathan Revusky wrote:
Bill wrote:
Henning
I think working on Freemarker support would be a waste of the developers
valuable time.
Bill,
I'm curious. Have you made some kind of point estimate on how long it would take developers to put back in the FM support?
Surely, it being a waste of time depends on how much time it actually is, doesn't it?
However, divorcing Turbine from Velocity to allow more
flexibility not only seems like a good idea, it seems absolutely
necessary if the I understand the path to Avalonization.
What is Avalonization?
Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ FreeMarker-Velocity comparison page, http://freemarker.org/fmVsVel.html FreeMarker 2.3pre4 is out!
-b
On Wed, 2003-06-18 at 06:41, Henning P. Schmiedehausen wrote:
Jonathan Revusky <[EMAIL PROTECTED]> writes:
Henning P. Schmiedehausen wrote:
Hi,
is anyone of you needing or missing FreeMarker Support in Turbine 2.2?
I believe the question should maybe be rephrased:
Is any one of you needing or missing decimal number support in Velocity?
Ok,
Folks, is anyone of you missing <insert your feature here that FM supports and Velocity does not> from the View portion of Turbine?
You will find a feature complete list on http://www.freemarker.org for FreeMarker and on http://jakarta.apache.org/velocity for Velocity.
If yes, would you consider a switch from Velocity to FreeMarker as View for Turbine or would you get a pull tool to support this feature?
The reason for this (and Jonathans' response): On the Velocity lists, there has been some rumbling about the current development state of Velocity and talking about alternatives to it. As we (Turbine) did remove the (quite aged and not actively maintained) FreeMarker support post Turbine-2.2, there have been some accusations of doing this because of "political reasons". As I was not really involved in the FM stuff or its removal, I'm trying to collect opinions from the Turbine users about getting FM support back into Turbine. However, if noone wants to use it, it wouldn't make much sense and the change itself is (IMHO) quite a major one to support FM really good.
Jonathan, some technical information (which you as a non-Turbine guy
might not have seen yet): Unfortunately the o.a.velocity.Context is
buried pretty deep in the Turbine code (this is legacy of the original
turbine developers). So we will have to replace this in every place
with an Adapter class with plugs either onto the Velocity Context or a
similar class in every other view solution (FreeMarker, WebMacro
etc.).
Doing so, it would be necessary for all of our users to change the imports in their self-written classes (Action, Screen), because the Context is part of the signature of the methods which are overloaded by user classes.
If we don't do this but just 'bolt FM support on' by using different classes, there wouldn't be much won, because people would still use VelocityScreen, VelocityPage etc. just as in all the example code around and the FM code would start to rot (again). I don't want this, because it wouldn't buy much for the Turbine users. So we would need some major core changes to allow developers to simply switch views without having to rewrite all of their classes later.
If we want to have engine-independent view support which is equal for all templating solutions (and not heavily Velocity based as the current view is, which is one of the reasons why noone really uses FM and/or WebMacro with Turbine and the code started to rot), we will have to make this (major) change. This is something that affects all of our users and we will listen to them.
Is anybody missing any of those features?
Please send opinions to this list. Turbine 2.3 is pretty much in feature-freeze state and I want to put out an RC until the end of next week (Colin, don't worry, your Intake changes will be in :-) ) and I'm already starting to collect ideas for 2.4-dev. However, moving to the pipeline and towards Avalon will (for me) stay top priority.
Regards Henning
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
