> -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 19, 2003 10:59 AM > To: [EMAIL PROTECTED] > Subject: Re: Decimal Number support > > > "Quinton McCombs" <[EMAIL PROTECTED]> writes: > > >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. > > As you already met one of the other big problems of our core > code (the fragility of some services that depend on the > correct init sequence), the best will be to rip out the > current Template, Pull, JSP and Velocity Service completely > (BTW: Everything under o.a.t.modules would go with this, too) > (rip out in this case means: Deprecate post-2.3) and replace > this with a new, pluggable architecture where the support for > a concrete templating engine is pretty much an afterthought.
I think this is a very good idea. I would like to propose that we consider supporting Velocity, JSP, XSLT, and perhaps FM as equally supported templating solutions. I think that by having this as a design goal we will end up with a truly pluggable solution. > The current Turbine view structure doesn't allow this. The > Code in Fulcrum is a little further down this road but it is > not really good, either. > > I'm not ashamed to admit that I will look around at Summit, > T3 and some more frameworks to 'steal' good ideas and I'm > pretty sure that I can come up with some more (even though I > might be accused of "just reinventing the wheel one more time > :-) ). But in the end I want to have all of this to be > _TURBINE_ code and support for a templating engine will be by > adding an adaptor for its context-like element (I'm pretty > sure that such a bugger is at the core of most templating > engines, because it is an easy way to get stuff from java to > template code), a factory to create new render elements and > then some extensions to screen and layout to plug it into the > template service. Summit does at least have a proxy class for the context type objects of the various templating engines. That is about as far as I have looked into Summits approach to pluggable view layers. > After all, our "class -> template" matching code is something > pretty unique in the web framework world and having the > ability to back layout and screen templates with java code, > build navigation structures from templates and match > templates with "superclasses" e.g. for the authentication is > something pretty unique to Turbine. I do want to keep this. > > Jonathan, what you don't see (and I don't hold it against > you, it took me ages to understand this), is the fact that > the FM and WM support in Turbine was never on pair with the > velocity support. The various screen and navigation classes > for Velocity were always more powerful that the FM and WM > support, which was only "bolted on". And this > (technical) aspect is IMHO the main reason that it wasn't really used. > > Look at the JSP view in Turbine. Yes, you can render JSPs > with the Turbine servlet, but the possibilities, especially > in terms of the pull code, are terribly limited. If you're > looking for a political decision in Turbine, then it is the > fact that the JSP View was kept even though it isn't really > good but keeping it gave us another "feature" when managers > were looking for a web framework to use. :-) (The average > manager is able to distinguish between "JSP" and "a > templating solution" but not between "some templating > solutions to choose from"). Very true. This is why I would like to see multiple templating engines have equal support within Turbine. > Putting the existing FM classes back into Turbine and getting > them to work with the most recent FM release might be a work > of some hours. But it won't really help the FM support in > Turbine, because you would be back at the situation described > above. One really well supported templating engine (Velocity) > and one (or more) basically useable but severely limited > engines (FM, WM, you name it). It would IMHO even hurt the FM > support in the long run because one of the arguments to work > on a template engine independent solution would no longer be valid. > > So IMHO we will have to make core code changes to get this > stuff to fly right. And this is neither the work of hours but > of days or weeks and we will have to make user-visible > changes which is a work of releases. > > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
