FAQ

[Turbine-user] FreeMarker Support

Colin Chalmers
Jun 19, 2003 at 5:03 pm
<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" <qmccombs@nequalsone.com>
To: "'Turbine Users List'" <turbine-user@jakarta.apache.org>;
<hps@intermeta.de>
Sent: Thursday, June 19, 2003 6:28 PM
Subject: RE: Decimal Number support

-----Original Message-----
From: Henning P. Schmiedehausen
Sent: Thursday, June 19, 2003 10:59 AM
To: turbine-user@jakarta.apache.org
Subject: Re: Decimal Number support


"Quinton McCombs" <qmccombs@nequalsone.com> 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
hps@intermeta.de +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: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
reply

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions