I don't see any advantage in using neither of them, but I am not up to date with Sitemesh 3, could you explain "More specifically, given the path of SiteMesh and how it will be mixing velocity and freemarker in SiteMesh 3, it seems that the best path would be to use the Servlet model and not the filter model in the future" a little, and why you think that using a servlet would be that much better?
musachy On Thu, Oct 22, 2009 at 11:48 AM, Christian Stone <xt...@stonescape.net> wrote: > I spent some time rethinking the architecture, and it seems like there is a > strong case to rethink the future of the struts2-sitemesh plugin. > > The current plugin uses and has used a new filter to override the > SiteMeshFilter code. SiteMeshFilter eventually leaves the dispatcher to > handle the request. This works for JSP, as it can easily access things like > static resources, but is a bit more difficult for Freemarker and Velocity > which do not compile against the java codebase before execution. > > The problem is that struts would like to inject things like properties and > static class variables into the value stack, and it does so with the > FreemarkerManager and VelocityManager classes. These two classes provide > the resources for evaluation of the appropriate files within the struts > result handling, but they do not provide the managers for the SiteMesh > decorators. > > After rethinking things a bit, I am wondering why the path of providing > filters to integrate into SiteMesh were used as opposed to providing a > custom Struts 2 FreemarkerServlet and VelocityServlet dispatcher. If the > latter choice were made, you could likely override the > preTemplateProcess(...) in the FreemarkerServlet class as an example of how > you can add the needed properties into Freemarker to evaluate without having > to dig inside of SiteMesh and other technologies. > > The second concern that I have is that you have a separate manager for every > technology you wish to support. If a developer wishes to include statics > and use both technologies, they have to include them twice. Perhaps a > custom manager for providing mapped and static resources would be better > that would be incorporated into the Freemarker and Velocity Managers. > Simply put, the TemplateMapProvider (or whatever it should be called), > would include all the statics resources and dynamic resources needed for any > template processing. > > I understand that I do not have a deep knowledge of the architecture of > Struts 2, so I ask why the first and not second path was chosen (the one of > providing filters). More specifically, given the path of SiteMesh and how > it will be mixing velocity and freemarker in SiteMesh 3, it seems that the > best path would be to use the Servlet model and not the filter model in the > future. So what am I missing? > > -- Christian Stone > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
