Daniel Rall <[EMAIL PROTECTED]> writes: Hi,
>This raises the question of exactly how to change it down the road. >My interest in the jakarta-turbine-2 repo is focused on the future, as >I want to see the appropriate parts of jakarta-turbine-3 repo merged >into it (and plan on helping with that when the time is right). Cool. I'll get back to you on this. ;-) >The decoupling of Fulcrum is definitely beneficial. The introduction >of the pipeline is great, offering many hooks for plugging in >additional functionality. As suggested by Ilka (a la Tami), I >recommend providing a Servlet API 2.3 Filter facade for it when it is >merged back into the next release of the jakarta-turbine-2. This will >provided better inter-op with today's popular technologies. Going API 2.3-only probably makes sense. We already have a service (Session Service) which requires 2.3. >However, as a developer and user of Turbine 3 + Fulcrum, I must >protest that the TemplateEngineService contains unnecessary complexity >that should be simplified before coming anywhere near the >jakarta-turbine-2 repo. You might want to take a look at the Turbine TemplateService. I rewrote it early this year and moved all the mappers out into mapper classes. I'd consider the Turbine code much cleaner than the Fulcrum-one. However, the Fulcrum code has less core dependencies, because it is developed with clean interfaces from the Core. [...] >Shall we codify this policy? Something like: > Support for new view engines will only be considered when there is > both demand from the user community and a Turbine developer (new or > existing) who has agreed to maintain it. Support is likely to be > dropped if there is no one available to do maintainence and there > are a proliferation of defect reports. >How's that sound? I don't like to "set these things in stone". If someone shows up that donates support for a templating engine and it is done in a clean way, I don't see no reason not to add it. And if it's done right, it won't fall prey to code rot as WebMacro and FreeMarker Support did. [...] >Yup. If you find the time to follow up to my response to Jonathan's >suggested template system abstraction, I'd be happy to take any >feedback into consideration, Avalonize it, and check that >ContentGenerationSystem in as a proprosal for the next major release. I've read it. One thing I want to avoid is to fall into the Turbine-3 trap: Putting too many major changes into one release: Basically, people that were struggling with Turbine-2 had to adapt to a new code structure (Turbine-2 -> Turbine-3, Fulcrum), lots of code-breakout and repackaging (Torque, Stratum, JCS, Fulcrum, lots of commons-stuff) which partly were simply a wrong way and abandoned half-baked (JCS, Stratum), a new core concept (Pipeline) and an ever breaking build tool (The beginnings of Maven, where Jason was using the Turbine repositories as his "testbed" (as he stated on one of the mailing lists some time ago)) and almost non-existed docs. In the end, most people simply gave up on the Turbine-3 code base, except those who really helped developing it. That's why there are almost no active Turbine-3 users (these seem to be jmcnally and you. Ilka went Tami, JvZ went Maven, Plexus, Summit, jon went somewhere completely else). Abandoning the user base with a half-finished project (which would have gone in the direction of Velocity if not a new generation of developers (mpoeschl, quinton, eric, yours truly) had cropped up) would have been a real shame as Turbine is IMHO one of the most-underestimated Jakarta projects. BTW: Something I read some days ago: This is from the O'Reilly book "Programming Jakarta Struts", p.15 --- cut --- Jakarta Turbine Turbine is a servlet-based framework and an open source Jakarta project. Currently, there isn't a great deal of documentation for Turbine, but it seems to be similar to Struts, with a few major differences. For one thing, it doesn't seem to be coupled to JSP. The focus of Turbine appears to be to provide a collection of reusable components. A large set of components is included with the framework, but they are quite disparate. It seems to present more of a component library, but as it's lacking documentation, it's hard to get a good feel for the complete architecture. More information can be found at http://jakarta.apache.org/turbine/. --- cut --- This sums the state of the current Turbine pretty nicely. "Cool stuff but noone knows about it, because the docs are lacking". 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 --- Quote of the week: "It is pointless to tell people anything when you know that they won't process the message." --- Jonathan Revusky --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
