Sitemesh buffering undecorated content

There's currently a problem with Sitemesh in that it buffers ANY content 
that is mapped to Sitemesh's PageFilter. This is obviously a bad thing, 
especially if there are images or other large files involved.

Currently there are a few workarounds:
1) Don't put any resources that aren't intended to be decorated in a 
path that will cause them to be caught by the Sitemesh filter.
2) Write another filter that disables Sitemesh via 
request.setAttribute(FILTER_APPLIED, Boolean.TRUE); for any resources 
you don't want decorated.
3) Ignore the problem :-) If the undecorated resources are small, it's 
not too much of an issue.

Obviously a proper fix would be preferable but the solution(s) I have in 
mind may harm backwards compatibility so I thought I'd better run it 
past you lot to see if there were any objections or better ideas on how 
to solve the problem.

Currently sitemesh-default.xml contains the following:

<page-parsers>
   <parser default="true" 
class="com.opensymphony.module.sitemesh.parser.DefaultPageParser" />
   <parser content-type="text/html" 
class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
</page-parsers>

This means that any text/html content will be handled by the 
FastPageParser, and ALL OTHER CONTENT is handled by DefaultPageParser. 
DefaultPageParser does absolutely nothing, but Sitemesh dutifully 
catches the response and passes it through to the DefaultPageParser for 
processing all the same.

So... the first part of my fix would be to remove the concept of a 
default parser (or at least make it optional). Is anyone actually using 
this? If so, what for? If I can get rid of the default parser then only 
the correctly configured content types need to be caught. This goes a 
long way to solving the problem.


There are still problems with content types that are mapped to a parser 
but don't need to be decorated (eg because they're not mapped to a 
decorator via <pattern> in decorator.xml, or mapped to a nonexistent 
decorator). This gets tricky though - some of the decorator mappers (eg 
PageDecoratorMapper) depend on the response to let them know if they 
should actually kick in or not.

There are two solutions that I can think of. One requires user 
intervention, the other is partly automated (but not foolproof).

1) Add support for excluding URLs from being decorated. I haven't 
thought this through, but I suspect we'd have to add an 
<exclude-pattern> tag to sitemesh.xml? Ideas?

2) The automated approach. DecoratorMapper interface gets the following 
new method:

boolean mightDecorate(HttpServletRequest request);

This method would let Sitemesh know whether a particular mapper thinks 
it may need to decorate the response. Mappers such as the 
FileDecoratorMapper or ConfigDecoratorMapper that knew they couldn't 
handle the request would delegate down the chain. Mappers that weren't 
sure (because they need the response to find this out), or knew they 
should definitely handle the response would just return true. The 
default implementation in AbstractDecoratorMapper would be to return 
true, which should aid backwards compatibility for anyone who's written 
a custom mapper.

If we manage to survive the chain with mightDecorate() returning 
'false', we know that this page doesn't need to be decorated, hence we 
don't need to bother wrapping the response.

Overkill/too complex perhaps?

Any thoughts/comments/criticisms appreciated! If we can settle on an 
approach to take, I'll go ahead and do the dirty work.

Chris



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click