> -----Original Message----- > From: Bill [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 8:15 AM > To: Henning P. Schmiedehausen > Cc: turbine-user > Subject: Re: Decimal Number support > > > Henning > > I think working on Freemarker support would be a waste of the > developers valuable time.
It would not be a waste of time is people are interested in using 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. I agree with you that the flexibility would be a very good thing. Our view architecture is really not very plugable. The problem is that once you start writing your actions and screen classes which accept RunData and Context as parameters, you are become tied to the view implementation. This was very much a shortcoming of the core design of Turbine. Hennings idea to create a proxy class to represent the context type object of the underlying view is indeed a good way to solve this problem. It would require deprecating the methods that everyone normally overrides in the screen and action classes. The replacement would be virtually the same interface replacing Context with the new class. Even if we do not decide to support FreeMarker, I think that it would be in our best interests to implement the proxy class for the context. Right now, if your view is JSP and you want to switch to Velocity or visa-versa, you must modify all of your action and screen classes. Not fun. > -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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
