<snip> 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. </snip>
Good idea to define the scope before hand and looks a good achievable list to me Colin ----- Original Message ----- From: "Quinton McCombs" <[EMAIL PROTECTED]> To: "'Turbine Users List'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 6:28 PM Subject: RE: Decimal Number support > > -----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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
