I have a working Struts 2 application where I am using Velocity AND
Freemarker decorators now intechangeably and SiteMesh is dispatching
them. The full value stacks are available in each, as the same
Configurations are running on both the decorators and the struts
results. You can now
I was never big on the Servlet or Filter models. It seems to me that
Struts2 is moving heavily towards conventions and the more things are
just pluggable the easier it will be for users. I feel that the best
approach would be for Struts2 to discover SiteMesh in the class path
and wire it
There is some time before SiteMesh 3 comes prime time, so there is
plenty of time for thought here. I do love the idea of wiring it up
directly...
However, since SiteMeshFilter requires the dispatcher to handle
requests, you would have to incorporate the SiteMesh filter directly
into
I've done some work with it and it looks to be completely pluggable. I
do this same thing in JCatapult with other libraries. Essentially, I
define a workflow chain in a configuration file that is the default
and it contains items that might not exists on the classpath. If a
specific
On Oct 23, 2009, at 12:01 PM, Brian Pontarelli wrote:
I've done some work with it and it looks to be completely pluggable.
I do this same thing in JCatapult with other libraries. Essentially,
I define a workflow chain in a configuration file that is the
default and it contains items that
On Oct 23, 2009, at 10:10 AM, Christian Stone wrote:
On Oct 23, 2009, at 12:01 PM, Brian Pontarelli wrote:
I've done some work with it and it looks to be completely
pluggable. I do this same thing in JCatapult with other libraries.
Essentially, I define a workflow chain in a
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
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
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
The first reference is just to look at JIRA issues regarding
flexibility, such as WW-2865
And flexibility is what I am speaking about. The new SiteMesh allows
a more tiled (recursive) decorator workflow, and allows for the mixing
of technologies (freemarker, velocity, and jsp). Using a
that sounds pretty reasonable to me. if you are up for the task, go
for it. 2.2 is far in the horizon and this would be a good time for
this kind of stuff.
musachy
On Thu, Oct 22, 2009 at 12:47 PM, Christian Stone xt...@stonescape.net wrote:
The first reference is just to look at JIRA issues
11 matches
Mail list logo
