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 workflow isn't there, I just de-activate it. This is
essentially how Struts2 would want to "determine" if SiteMesh 3 is in
the classpath. If it is, it would wire things up. If not, it would de-
activate that part of the filter-chain.
In terms of SiteMesh 3 being capable of being called programmatically,
last time I looked this was one of the primary goals. The API was well
defined and it allowed SiteMesh to be invoked from nearly any code. I
recall some discussion of allowing it to be used outside of a servlet
container as well. I'll have to circle back and see if that is
possible. I was also planning on incorporating SiteMesh into the
JCatapult email library so that emails could also be decorated.
Once I get that stuff going, I'll let you know. I also will try and
work with the SiteMesh developers on ensuring the integration is as
generic and simple as possible.
-bp
On Oct 23, 2009, at 9:35 AM, Christian Stone wrote:
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 the struts filter chain, and I think this would require struts
to absorb much of the sitemesh codebase (unless the SiteMesh
developer were to refactor the code a whole lot more to allow it to
plug in to other filters and not be a filter on its own). The same
thing would go for the dispatchers, since struts would have to
insert them on the chain as well. It does seem like a lot of work
without a noticeable benefit to the users (they still have to
configure a decorators file, etc., and which filters/dispatchers are
potentially causing conflicts would be hidden from the user).
Additionally, they still would have to configure the dispatcher, at
least for the request mapping, and I think it is less intuitive to
put it into a struts config file than web.xml where they are used to
such configurations (again, at this time).
With all that said, if you want to take on the task of working with
SiteMesh 3 and making it truly pluggable and modular (such as a
JCatapult module), that would be awesome. Once that happens the
work on the Struts side shouldn't be so bad (presuming the core
architecture is in place)! If the convention of Struts is to
configure and deploy everything, including JSP dispatcher, etc. then
I love the idea!
-- Christian
On Oct 23, 2009, at 11:13 AM, Brian Pontarelli wrote:
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 up automatically. I'd also wonder if
this could be another case for some additional annotations in
addition to XML configuration for defining templates.
Anyways, this is how I would proceed and leverage SiteMesh 3. This
is my plan for JCatapult.
-bp
--
_,--"
cws `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ Christian Stone, Software Engineer / | |_\\
(_____|_|__= xt...@stonescape.net =__|_|_____)
_\_____=__ http://xtian.stonescape.net/ ___/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
