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. 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. 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. 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. 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] -- Bill <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
