-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Revusky Sent: Friday, June 20, 2003 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Decimal Number support
<snip>
they merely discussed if they should
"bolt it on" (making some hacks here or there, if i
understood correctly), or
do it right (which would lead to a major redesign of their
product).
Oh, the technical stuff is all fine.
As I explain above, I just get very sensitized to hearing nonsense. That's all.
Nonsense? Could you explain how that is nonsense?
I really don't want to rehash all this. But you are asking the question and I shall respond. The nonsense I was referring to was the business about the FM support being removed because "nobody was using it". I have already explained why I consider that to be a very contrived half-truth. There has been other nonsense that has got my back up too, but I don't want to rehash it all.
I am getting sensitized to nonsense, and even in the best of circumstances, I don't suffer it gladly. Maybe it really did take Henning "ages" to figure out that other template engines were never supported on an equal footing with Velocity in the Turbine framework. I couldn't make any sense of that, and it got my back up.
I was already sensitized from previous dialogue to what I perceived as rather contrived, dishonest arguments and things, and my irritation definitely showed through.
Turbine is a pretty good product. However, it has a fair amount of
legacy code in it in which the design is a buit lacking to put it
nicely. This was what the current developers have inheritied and are
trying to rectify. These core design issues are what made the support
for FM, JSP, and WM less than optimal.
That's fine. I processed all that.
I was not around for the discussions of why things were done as they were. I don't really care to know either. If I had to guess, the active developers at the time used Velocity and were happy with it.
Well, I'm only moderately familiar with all this, but I do happen to know that the original author of Velocity is really Jon Scott Stevens, who was also main developer of Turbine originally. Velocity began basically as a WebMacro clone, which was written by Jon because there was some personal falling-out between him and Justin Wells, the original WM author. WM was slated to become a Jakarta project, but then JS wrote a clone that became Velocity. In fact, in its earlier incarnations, I believe that Turbine supported WM and FM. WM was supposed to become a Jakarta project, but then JS wrote Velocity, probably as a kind of in-your-face one-upsmanship sort of thing.
After that, I think the support for multiple template engines was something of a farce. Velocity usage was favored intentionally. The FM support was never kept up-to-date despite the absolutely minimal effort it would have required. I think you can definitely say that the emphasis on Velocity and the coupling you refer to was not something that came about based on purely technical considerations.
I understand perfectly well that you and Henning had nothing to do with all this. Of course, given that, I don't see why you feel the slightest need to defend any of the prior foolishness.
Now, when I state that I am not that favorably disposed towards actively helping you put the FM support back, there is a history here. If, instead of simply removing the FM support, you had showed up in our community and solicited our help in bringing it up-to-date, I think we would have helped you. At this point, I do sort of feel strongly that it's up to you guys to put it back in.
They probabley made improvements to the product in the areas that directly affected what _they_ were using Turbine for. Since they used Velocity, they developed in those areas. This is all just speculation based on what I have see from other projects.
Let's let it rest. I think I know pretty much what happened. Or at least, I know what happened as well as I care to.
Now, I understand that FM will be able to transparently use a Velocity context object. We _could_ take that approach and put FM support back into Turbine fairly quickly. Personally, the idea seems revolting to me. From a design perspective, I would wonder what the developer was smoking who implemented FM support using a Velocity context object.
I asked Henning in the message that he flamed me over whether this VelocityContext thing was the only real sticking point. I don't believe he answered. If it is, I just don't think it's a big deal.
Frankly, I think you probably should implement the solution I gave you. It actually *looks* much more screwy than it is. You see, you can pass in a java.util.HashMap to FM and it converts it transparently to the internal thing it needs. Using the same ObjectWrapper API. For all of it, a VelocityContext is just a hashtable. That, for historical reasons, you're using VelocityContext there instead of java.util.HashMap or some other thing, is really kind of a little wrinkle.
It's like something that *looks* like bad design, but is more like a little implementation wrinkle. As for being concerned about what other people will think when they see that, that's.... maybe.... (a bit silly ;-))
I am not opposed to putting FM support back into Turbine. I have looked over the docs and I am quite imnpressed with the product. I think that it would benefit our users to have something other than Velocity to choose from on the view layer. Granted, there is JSP but the support for that is not on par with Velocity.
I do not want to see another quick hack put into this project. We need
to take a step back and decide how we are going to restructure the inner
workings to allow for multiple view technologies all having equal
integration into our product. If we do this correctly, we can not only
easily add FM support but support for other choices as well.
Well, basically, the XP principle of doing the simplest thing that works until a need is proven for something more sophisticated should probably apply. I mean, the obsessive desire with doing the grand theoretically correct refactoring strikes me as possibly counterproductive in this instance.
At the end of the day, any object you use as the root of the data model is just a hashtable. VelocityContext is as good a hashtable as any other, probably.
If you were going from scratch, you wouldn't do it that way, but given the corner you've been painted into, I think you might as well go that route now.
And the other thing I wonder is why you can't just use java.util.Object where you were using VelocityContext. Then the Velocity-specific implementation could cast it to VelocityContext. The FM implementation could deal with the VelocityContext transparently, and other solutions would need a different kind of object passed in, but you could deal with that later when the need shows up.
That would just require that people recompile against the newer jarfile, because the method signatures would change. But that's hardly a big deal. Where they explicitly passed in a VelocityContext object, they could just continue doing so.
from this point of view, you seemed to have achieved your goal.
It was never much of a goal of mine, you know. Henning brought it up on the Velocity list. He suggested that I should provide a patch, and I said quite matter-of-factly that that was not going to happen, since, Turbine removed support for alternatives for rather murky non-technical reasons, AFAICS, and my position really just had to be that, if you guys wanted FM support back, you had to put it back yourselves.
Then Henning started all this stuff about how we were nutty conspiracy theorists for believing that the removal of FM or WM support and leaving only Vel support was political in nature.
He said, she said, BS. Does this really matter? If the two of you want to continue that particular thread of the discussion, please take it off the list.
Well, I was just explaining how we got to that point. You're also trying to explain a bunch of things.
In any case, I think there are a couple of things that really got my back up. I'll explain them below and be done with it.
I think it appropriate to re-iterate what I said in a previous message. If you want to foment constructive discussion and activity, I think you first need to foment more honesty in the basic culture here.
You guys should stop these attempts to spin and distort what's really going on.
You are certainly welcome to your opinion but I think that you have mis-understood what Henning was saying about why it was removed. Henning was not the person that removed it. That decision was made before either of us started working on the project. He told you his understanding of the reasons behind the removal. If you choose to believe that he is not being honest about it, ask someone else. There is no need to accuse people of not being honest. He is being honest as long as what he tells you is what he believes to be true. It really has nothing to do with if it is the _real_ truth or not. But again, does any of that matter??
This could just be a misunderstanding. In general, if you're 100% honest, it's pretty easy to get along with me.
These are the 2 basic things that got my back up:
1. This stuff about everybody having chosen Velocity and nobody wanting FM -- this seems very dishonest to me, because the two things were never competing on an equal footing. It's a contrived argument based on a rigged situation.
2. The implicit idea that I am the one in a supplicant position asking *you* for something. "If you want the FM support in there, submit a patch". Quite literally, there seems to be this idea that, by leveraging *our* community's hard work, you are doing *us* a favor. You can deny that this was ever insinuated, but I have inferred this subtext.
To be brutally honest, Turbine gains a lot more from FM integration than we do. You say you've looked through the FM docs, so I think you know that what I'm saying is true. And the truth should be something that is respected.
Anyway, my honest advice to you guys is to put in the support the quick, easy way. It's a bit screwball, but it's not particularly bad on design/architectural grounds. I really don't think so. It's mostly just annoying on aesthetic grounds, not pragmatic ones.
Best Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
