You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Christian Stone <xt...@stonescape.net> on 2009/10/22 20:48:09 UTC
The future of sitemesh integration with struts 2...
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-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Brian Pontarelli <br...@pontarelli.com>.
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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 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
>
>
> This sounds great! I was just reviewing the alpha SiteMesh3 and
> while it is far from complete it still seems to be tied to the same
> filter/dispatcher architecture. Perhaps if SiteMesh allowed for
> configurable renderers... now that would be great!
Check out all the offline and builder stuff in there. You can build a
Context yourself or use the offline or webapp Contexts. Plus,
everything passed to the Context's constructors are interfaces. There
are a number of implementations of these interfaces that you can use
or you can provide your own implementations.
In SiteMesh 3 the decorators are just HTML. This means that I can use
this process to handle everything:
1. Render the result FTL into HTML
2. Render the decorator FTL into HTML
3. Pass the result and decorator HTML to SiteMesh 3
4. SiteMesh spits out the final HTML
5. Push final HTML to client
Should be very straight-forward in fact.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Christian Stone <xt...@stonescape.net>.
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 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
This sounds great! I was just reviewing the alpha SiteMesh3 and while
it is far from complete it still seems to be tied to the same filter/
dispatcher architecture. Perhaps if SiteMesh allowed for configurable
renderers... now that would be great!
-- Christian
--
_,--"
cws `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ Christian Stone, Software Engineer / | |_\\
(_____|_|__= xtian@stonescape.net =__|_|_____)
_\_____=__ http://xtian.stonescape.net/ ___/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Re: The future of sitemesh integration with struts 2...
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 / | |_\\
> (_____|_|__= xtian@stonescape.net =__|_|_____)
> _\_____=__ http://xtian.stonescape.net/ ___/_
> \/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Christian Stone <xt...@stonescape.net>.
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 / | |_\\
(_____|_|__= xtian@stonescape.net =__|_|_____)
_\_____=__ http://xtian.stonescape.net/ ___/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Re: The future of sitemesh integration with struts 2...
Posted by Brian Pontarelli <br...@pontarelli.com>.
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
On Oct 23, 2009, at 8:38 AM, Christian Stone wrote:
> 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 have decorators in Freemarker, Velocity, and
> JSP as long as the servlets are defined in your web.xml. I had to
> make a lot of changes to bring the plugin up to date with the modern
> freemarker, so good that this will be getting in early! Note that
> the old plugin fix I did is still there, so you can use either of
> the two published solutions you wish, and you no longer are using a
> crippled Freemarker with the new solution (shown below).
>
> I think my chin dropped when I saw all the decorators mixed in one
> decorator.xml and compiling. I am accessing all my statics in my
> freemarker decorator (velocity 1.3 does not support such things), so
> that is fixed as well. Absolutely sweet! On another note, I was
> able to streamline the process a bit, so there should be a subtle
> speed improvement as well.
>
> Here is an example web.xml snippet with the new changes hilighted.
> Currently I read the configuration from freemarker.properties as
> well as velocity.properties, and add any parameters present in the
> servlet, so the init phase for the two technologies is a bit more
> flexible and dynamic.
>
> <filter>
> <filter-name>struts-prepare</filter-name>
> <filter-
> class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter</
> filter-class>
> <init-param>
> <param-name>actionPackages</param-name>
> <param-value>net.stonescape.renegade20.presentation</
> param-value>
> </init-param>
> </filter>
>
> <filter>
> <filter-name>sitemesh</filter-name>
> <filter-
> class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>
> </filter>
>
> <filter>
> <filter-name>struts-execute</filter-name>
> <filter-
> class>org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter</
> filter-class>
> </filter>
>
>
> <filter>
> <filter-name>timing</filter-name>
> <filter-class>net.stonescape.common.filter.TimerFilter</
> filter-class>
> </filter>
>
>
> <filter-mapping>
> <filter-name>timing</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-prepare</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
> <filter-mapping>
> <filter-name>sitemesh</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> <dispatcher>INCLUDE</dispatcher>
> </filter-mapping>
> <filter-mapping>
> <filter-name>struts-execute</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> <servlet>
> <servlet-name>sitemesh-freemarker</servlet-name>
> <servlet-
> class>org.apache.struts2.sitemesh.FreemarkerDecoratorServlet</
> servlet-class>
> <init-param>
> <param-name>default_encoding</param-name>
> <param-value>UTF-8</param-value>
> </init-param>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>sitemesh-freemarker</servlet-name>
> <url-pattern>*.ftl</url-pattern>
> </servlet-mapping>
>
> <servlet>
> <servlet-name>sitemesh-velocity</servlet-name>
> <servlet-
> class>org.apache.struts2.sitemesh.VelocityDecoratorServlet</servlet-
> class>
> <init-param>
> <param-name>default_encoding</param-name>
> <param-value>UTF-8</param-value>
> </init-param>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>sitemesh-velocity</servlet-name>
> <url-pattern>*.vm</url-pattern>
> </servlet-mapping>
>
> -- Christian Stone
>
> On Oct 22, 2009, at 4:00 PM, Musachy Barroso wrote:
>
>> 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
>
> --
> _,--"
> cws `-._ ________-_______ "----
> _----'--'--------------------------------'--'----_
> //_| | \ Christian Stone, Software Engineer / | |_\\
> (_____|_|__= xtian@stonescape.net =__|_|_____)
> _\_____=__ http://xtian.stonescape.net/ ___/_
> \/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Christian Stone <xt...@stonescape.net>.
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 have decorators in Freemarker, Velocity, and JSP
as long as the servlets are defined in your web.xml. I had to make a
lot of changes to bring the plugin up to date with the modern
freemarker, so good that this will be getting in early! Note that the
old plugin fix I did is still there, so you can use either of the two
published solutions you wish, and you no longer are using a crippled
Freemarker with the new solution (shown below).
I think my chin dropped when I saw all the decorators mixed in one
decorator.xml and compiling. I am accessing all my statics in my
freemarker decorator (velocity 1.3 does not support such things), so
that is fixed as well. Absolutely sweet! On another note, I was able
to streamline the process a bit, so there should be a subtle speed
improvement as well.
Here is an example web.xml snippet with the new changes hilighted.
Currently I read the configuration from freemarker.properties as well
as velocity.properties, and add any parameters present in the servlet,
so the init phase for the two technologies is a bit more flexible and
dynamic.
<filter>
<filter-name>struts-prepare</filter-name>
<filter-
class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareFilter</
filter-class>
<init-param>
<param-name>actionPackages</param-name>
<param-value>net.stonescape.renegade20.presentation</
param-value>
</init-param>
</filter>
<filter>
<filter-name>sitemesh</filter-name>
<filter-
class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>
</filter>
<filter>
<filter-name>struts-execute</filter-name>
<filter-
class>org.apache.struts2.dispatcher.ng.filter.StrutsExecuteFilter</
filter-class>
</filter>
<filter>
<filter-name>timing</filter-name>
<filter-class>net.stonescape.common.filter.TimerFilter</
filter-class>
</filter>
<filter-mapping>
<filter-name>timing</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>struts-prepare</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>sitemesh</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>struts-execute</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>sitemesh-freemarker</servlet-name>
<servlet-
class>org.apache.struts2.sitemesh.FreemarkerDecoratorServlet</servlet-
class>
<init-param>
<param-name>default_encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>sitemesh-freemarker</servlet-name>
<url-pattern>*.ftl</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>sitemesh-velocity</servlet-name>
<servlet-
class>org.apache.struts2.sitemesh.VelocityDecoratorServlet</servlet-
class>
<init-param>
<param-name>default_encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>sitemesh-velocity</servlet-name>
<url-pattern>*.vm</url-pattern>
</servlet-mapping>
-- Christian Stone
On Oct 22, 2009, at 4:00 PM, Musachy Barroso wrote:
> 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
--
_,--"
cws `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ Christian Stone, Software Engineer / | |_\\
(_____|_|__= xtian@stonescape.net =__|_|_____)
_\_____=__ http://xtian.stonescape.net/ ___/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Re: The future of sitemesh integration with struts 2...
Posted by Musachy Barroso <mu...@gmail.com>.
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 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 filter architecture
> means tying struts codebase to both the details of Freemarker AND SiteMesh.
> Using the servlet model means not being bound by changes in the SiteMesh
> filters/code at all. You could use Freemarker, Velocity, and JSP in
> SiteMesh (all together), not tie yourself to the SiteMesh codebase with the
> plugin, and still have all the benefits you have now.
>
> In one case, you can write a filter, and have to re-implement a whole bunch
> of SiteMesh code. This code has been completely rewritten for SiteMesh 3,
> so the plugin work will have to be redone again for it. Since we are
> overriding the dispatcher, you also have to include what file extensions
> will map to Velocity, and Freemarker and implement all the logic that the
> request dispatcher uses. Integration of Velocity, Freemarker, and JSP will
> need to happen, because otherwise Struts will cripple SiteMesh 3 (worse than
> it does with SiteMesh 2).
>
> On the other hand, you can override the Servlets for Velocity and
> Freemarker, and in that case (at least with the Freemarker one), there are
> great code points where you can inject your mappings without having to
> reinvent anything. It seems to be very clean cut. If any of the two
> technologies changes, likely the servlets will still work, as the functions
> we override are specifically there for customers to override. We won't have
> to respond to SiteMesh changes, and we won't be broken at all with respect
> to the SiteMesh design.
>
> Really, even with SiteMesh 2, there is a strong argument for taking the
> route of servlets instead of filters for tying into Freemarker.
>
> I hope this is all reasonable. I am typing this hastily in hopes that it
> will give you what you need without delay...
>
> -- Christian
>
>
>
>
>
> On Oct 22, 2009, at 3:08 PM, Musachy Barroso wrote:
>
>> 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
>
> --
> _,--"
> cws `-._ ________-_______ "----
> _----'--'--------------------------------'--'----_
> //_| | \ Christian Stone, Software Engineer / | |_\\
> (_____|_|__= xtian@stonescape.net =__|_|_____)
> _\_____=__ http://xtian.stonescape.net/ ___/_
> \/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: The future of sitemesh integration with struts 2...
Posted by Christian Stone <xt...@stonescape.net>.
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 filter
architecture means tying struts codebase to both the details of
Freemarker AND SiteMesh. Using the servlet model means not being
bound by changes in the SiteMesh filters/code at all. You could use
Freemarker, Velocity, and JSP in SiteMesh (all together), not tie
yourself to the SiteMesh codebase with the plugin, and still have all
the benefits you have now.
In one case, you can write a filter, and have to re-implement a whole
bunch of SiteMesh code. This code has been completely rewritten for
SiteMesh 3, so the plugin work will have to be redone again for it.
Since we are overriding the dispatcher, you also have to include what
file extensions will map to Velocity, and Freemarker and implement all
the logic that the request dispatcher uses. Integration of Velocity,
Freemarker, and JSP will need to happen, because otherwise Struts will
cripple SiteMesh 3 (worse than it does with SiteMesh 2).
On the other hand, you can override the Servlets for Velocity and
Freemarker, and in that case (at least with the Freemarker one), there
are great code points where you can inject your mappings without
having to reinvent anything. It seems to be very clean cut. If any
of the two technologies changes, likely the servlets will still work,
as the functions we override are specifically there for customers to
override. We won't have to respond to SiteMesh changes, and we won't
be broken at all with respect to the SiteMesh design.
Really, even with SiteMesh 2, there is a strong argument for taking
the route of servlets instead of filters for tying into Freemarker.
I hope this is all reasonable. I am typing this hastily in hopes that
it will give you what you need without delay...
-- Christian
On Oct 22, 2009, at 3:08 PM, Musachy Barroso wrote:
> 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
--
_,--"
cws `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ Christian Stone, Software Engineer / | |_\\
(_____|_|__= xtian@stonescape.net =__|_|_____)
_\_____=__ http://xtian.stonescape.net/ ___/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Re: The future of sitemesh integration with struts 2...
Posted by Musachy Barroso <mu...@gmail.com>.
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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org