Jonathan Revusky wrote:
All fun and games. I don't have much time for it.
ROTFL. You clearly have more time on your hands than most.
Point taken. My telling you guys off was clearly self-indulgent and I was conscious that I was wasting my time. It is pointless to tell people anything when you know that they won't process the message.
I think we are by now all pretty clear as to your opinions
Thank you. I think I have expressed myself quite clearly and if anybody doesn't understand what I'm saying at this point, it's willful.
and are ready to move on.
Well, I'm not optimistic on that. I sense that a lot of people here are in a state of arrested development.
When I saw that founding members of the project, in particular Jon Stevens, were not involved any more, I had a flash of optimism about this. Also, there did seem to be some somewhat reasonable people. However, now I think the basic "culture" established by the original developers persists.
Also, I broke down and eyeballed the code yesterday, did a checkout. I grepped over the sources and saw that 21 (!) different source files reference classes in the org.apache.velocity.* hierarchy.
Given that all you need to do basically, (in pseudocode) is:
Get Template Stick your variables in a context (which is just a hash) merge the template and data
How there are 21 different coupling points with the rest of the framework is beyond me. The Niggle framework (which I am the author of) supports FM, Vel, and WM. I did a similar grep and there are 3 files which reference Velocity classes. I did a similar grep over JPublish sources, which support the same 3 template engines. There are 4 source files that reference org.apache.velocity classes. In both cases, one can look at those 3 or 4 files, and it is quite easy to get a feeling of what would be necessary to support another template engine, what hooks you would need to replace.
From this examination of the Turbine code, I came to the unappealing conclusion that, when Henning and a couple of other people who know the code proposed that I submit a patch against the CVS HEAD, the suggestion was not made in completely good faith. They would have to do a cleanup to get the coupling down before it is feasible for me to come in and do that.
But anyway, at the end of the day, what is the point of having such a highly abstracted framework if you can't replace a given component of it without a major re-architecture?
The whole thing does not inspire much confidence.
Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
Regards,
Scott
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
