Henning I think working on Freemarker support would be a waste of the developers valuable time. 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.
-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 -- Bill <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
