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 -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
