--- "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote: > Jim Seach <[EMAIL PROTECTED]> writes: > > Hi, > > >Would it make any sense to support view/template engines by > forwarding > >to a view-specific servlet (like the newly released > >VelocityViewServlet) and communicating with all view engines through > >request, session, and application attributes? That way you let the > >Servlet mapping function of the Servlet container choose the view > >engine and they would all be on the same footing. It would be the > >responsibility of the view engine's servlet to make the Turbine > objects > >available to the engine in the proper manner. > > IMHO, no. Mainly because (as far as I understand the function of > VelocityServlet), this is already part of the Turbine Servlet (which > is, in fact, one big servlet. ;-) ). I haven't heard of > VelocityViewServlet, where can I find this?
It's part of the just released Velocity-Tools project. See http://jakarta.apache.org/velocity/tools/index.html Basically, the VelocityViewServlet (VVS) assumes the developer has put whatever the view requires into one of the Servlet contexts then has done a forward or include to a URL that maps to the VVS. The VVS constructs a Velocity Context from the attributes from ServletRequest, HttpSession, and ServletContext and also from a configurable Toolbox, locates the template, and renders it. It allows Velocity to be used in place of JSPs in a WebApp without requiring any changes to the WebApp logic. For example, VVS permits a Struts developer to Velocity in place of or alongside JSPs without changing any of the Struts classes. > > We use our java-class broker to return render classes for "now take > this file and render it as <xxx>-template". This maps your template > name to a java class name. Most of the time, it comes out as "use the > VelocityPage class to render this template". Because the > VelocityService (see below) has registered the VelocityPage class as > the page render class for templates, ending in .vm > Using the VVS approach, you would just need to map a logical page/template name to a URL and use the Servlet API to figure out the proper view servlet to call based on the servlet mappings. > VelocityPage is coupling point between the class-based assembler > broker (in the AssemblerBroker Service) and the actual template > mapping engine (which came later into play when Turbine was already > busily serving web applications with a java based view). > > VelocityPage prepares the Context by pulling it from the > VelocityService (which is the Factory that builds up and tears down > the Context objects and is also the initialization point for the > Velocity View engine) and then maps your template to an actual > template file (this is scope of the TemplateService), renders it (by > using Screen, Layout and optional Navigation) and returns it to the > container. Rather than use a VelocityContext it could prepare a TurbineContext, put it in a ServletRequest attribute, then use the xxx-ViewServlet to render the desired view. > > About supporting other templating engines on "equal footing": This > makes two assumptions: > > a) The current code surrounding the view engine is abstract enough to > > be templating engine neutral. > Or that it can be refactored to make it so :^) > b) There is interest enough interest from Turbine developers to > support > a second, third, fourth, fifth engine. > If there is no interest in making the code more generic it won't get done, but based on this discussion it seems like some of the developers see it as a positive (if low priority) thing to do, so if someone puts in the effort to do this it might be accepted. > > For a): Most of the code is. Some is not. This will change post-2.3 > > For b): There are much more interesting fish to fry and code to > write. At least I have no intention to do so in my _spare_ > time. > Personally I have a templating engine that fills all my needs > and I > see no reason to reinvent the wheel. If a developer or a > project > needs an <xxx>-view, well, they can communicate with the > Turbine > developers to donate code (that is what open source is all > about) > or they can contract one of us to write it for them. > Well, I don't particularly like JSP, ASP, or similar view technologies because it makes it too easy (and therefore tempting) to put business and controller logic into the template. I would rather take a little more time to develop a more maintainable system. I like Velocity because of its simplicity: if something is hard to do even with a tool, it probably shouldn't be in the view. I don't *need* support for other view technologies, but I was just wondering if by changing the approach it would both simplify Turbine and allow for other view engines. Some people prefer JSP or Freemarker over Velocity, and if Turbine supported them, it may attract more users (and developers). > Regards > Henning > Thanks, Jim Seach > -- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
