I guess what is needed is a volunteer! A first step would maybe be to submit a patch similar to what you recommend for making FreeMarker work with VelocityContext. This would allow interested users the opportunity to start looking at FreeMarker. Then, when the decoupling of Velcocity/Turbine is done, then we can quickly move to supporting Velocity and FreeMarker. To be honest, since I don't know my way around FM, I am probably not going to do the whole decoupling, workaround patchs. It needs to come from someone who is convinced the FM is better/needed. If they submit patch's (hint hint) to get FM working with Turbine as is, then maybe for my next project I can look at prototyping it using FM versus Velocity.
Eric -----Original Message----- From: Jonathan Revusky [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 11:38 AM To: [EMAIL PROTECTED] Subject: Re: Decimal Number support Tyler Burd wrote: > I don't think Velocity has reached EOL just yet - there has recently > been quite a bit of discussion on the Velocity dev list regarding > recommencing active development and integrating several user patches. Well, I am not the most objective source of information on this topic, as anybody can see from my sig. But the extremely neglected state of the Velocity project is really an objective fact. To all intents and purposes, nobody has committed any code for a year. You can see that from examining the archives of the velocity-dev list. Their last release, 1.3.1 final was in March, but that is deceptive, since 1.3.1 final was identical to 1.3.1rc2, and was AFAICS put out for marketing reasons, to give the impression that something was happening. Believe me, Velocity, as a project, is in a very neglected state. For example, the user patches that they are discussing in the "recommencing" thread, the map support and decimal number support, were submitted last autumn. Like 8 months ago! That's really not very confidence-inspiring for anybody who will be in a position of relying on Velocity. As for whether they are going to get moving again, for the moment that is all talk. I think that once development has stalled for that long, it's easier said than done. You know, if I don't work on code for a year, I forget my way around. It becomes very difficult to get back in. Right now, I know the FM codebase like the back of my hand, but if I didn't do anything there for a year or more... > > BUT, I know that if Turbine DID support other template dialects, I would > probably at least give FreeMarker a try, since it has some nice features > that Velocity doesn't, like the including of templates in a location > other than the template base directory, the compress directive, etc > (from a quick look at the manual). If I discovered I liked Velocity > better after spending some time with fm, I would switch back. It's the > fact that Turbine doesn't support fm and other template dialects that > prohibits me from trying alternative solutions. It seems to me that offering a choice is just clearly better. And there are certain fallacies in the air in this regard. Even if party X has won the elections by a landslide for the last 20 years and seem to be governing fairly well, is that an argument for introducing a one-party state? The fact that they can be voted out of power is what keeps the ruling party honest. (Okay, I mean less crooked, they are politicians, of course...) Similarly, at least having the option of switching to another template engine could be quite important for people. > > If it's not a huge headache, I vote for the proxied Context as well. If > the api was similar enough to the VelocityContext currently used, > converting screens and actions could just be a matter of changing the > import statements, and that could be done with a quick search & replace > on the source files and a recompile. As I pointed out in a separate note, FreeMarker (via a custom ObjectWrapper instance) could even be configured to work transparently with VelocityContext objects. It's quite easy. I'm hesitant to make this following point, since this whole thing about whether removal of FM support was political or not is not something I want to keep debating with anybody. It's all water under the bridge. But, once you know how relatively easy it is to keep the FM support working, and given the fact that offering choice is clearly better, it is hard to make sense of what happened. Also, the fact that people would create this coupling between Turbine and core Velocity classes makes one wonder how interested these people were in really giving people a choice between multiple template engines. But it's a sterile debate. If what happened before was a mistake, then the obvious thing to do is to correct that mistake. Best Regards, Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Velocity-FreeMarker template conversion utility, http://freemarker.org/usCavalry.html > > -Tyler Burd > > -----Original Message----- > From: Scott Eade [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 9:24 PM > To: Turbine Users List > Subject: Re: Decimal Number support > > > At the end of the day, if Velocity has reached EOL then we will at some > stage have to consider a new way forward. If FM is being actively > developed and provides a good migration path then it is a likely > candidate for consideration. > > Nobody seemed to express any concerns when WM, FM and Jython support was > removed, but at that point in time Velocity was still being actively > developed (and as Jeffrey points out Turbines support for all of the > others was not). If I was new to Turbine today I think I would be > questioning the logic of using Velocity for my templates, but then again > if there was no support for anything else then I wouldn't really have a > choice would I :-) If FM was supported and there was at least a sample > of app that used it then I would probably consider it. The biggest push > to use something other than Velocity would be if the Turbine site said > something like "Velocity is really great, but no longer being > maintained, we recommend you use ??? instead". > > As a general direction I think it would be great if we at > least look at relaxing the coupling between turbine and velocity such > that it would be easier to hook some other template service in should > someone have the desire and cycles to put it together. > > Cheers, > > Scott > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
