"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes: ... > What Mr. Revusky does not understand (because he has his hands over > his ears and screams at the top of his lungs, that "you must bring > your house in order" and "you have 21 coupling points to velocity in > turbine"), that actually Turbine has _one_ coupling point (the rest > are velocity related classes which can be replaced in a breeze with > "xxx-templating engine" related classes), which is unfortunately > embedded deep in another service (not templating related): the Pull > Service. Changing this (by either using a Map-based interface or an > adapter class) would mean an user visible break which according to the > deprecation rules must be pulled over one full release cycle. Actually > fixing the code is a matter of some minutes.
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). > The Turbine-3 code base got this right, which is a result of the > pipeline and the decoupling of Fulcrum. However, this doesn't mean, > that Turbine-2 can't stea^Wlearn from it. ;-) 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. 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. > This is the same thing as with SecurityService and Torque. The > SecurityService has a org.apache.torque.Criteria object embedded in > its interface. This makes it very hard to write a non-torque-dependent > Security Service implementation. Yes. > The problem for some people is, that our two main view types of > interest (Velocity and JSP) are already supported by Turbine-2 and > there is no real pressure besides from "special interest groups" to > get another view logic. 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? > Working on the pull service is one of the things for post-2.3 to > me. I'm pretty sure that what will materialize will be able to work > well with all kinds of templating solutions. Getting the Template > Service to work with Factories (which are currently wrapped a little > cumbersome into JspService and VelocityService) is an easy thing and > after some Avalonziation I'm pretty sure that Turbine will have a View > engine which is much superior to our current code. 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. -- Daniel Rall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
