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
