From my conversations with Joe, integration will be much simpler with
the next version. I'm looking at using the next version so that all
the templates are FreeMarker and I will be able to create my own
FreeMarker root context. It also looked like everything was going to
be extendable or overridable and it will also provide programmatic
access to everything so that it can be invoked from nearly anywhere.
SiteMesh has moved out of Open Symphony to Github and the new sitemesh.org
site. It doesn't look like anything new has happened since
September. Perhaps we need to rally around SiteMesh and help get that
project to 3.0 since it will benefit so many projects, including
Struts 2.
-bp
On Oct 22, 2009, at 12:48 PM, Christian Stone 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
