"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.
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.
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").
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]
