[prev in list] [next in list] [prev in thread] [next in thread]
List: opensymphony-sitemesh
Subject: [Opensymphony-sitemesh] Sitemesh buffering undecorated content
From: Chris Miller <chris.miller () swebtec ! com>
Date: 2004-05-17 23:17:39
Message-ID: c8bh6h$vbg$1 () sea ! gmane ! org
[Download RAW message or body]
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
_______________________________________________
Opensymphony-sitemesh mailing list
Opensymphony-sitemesh@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensymphony-sitemesh
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic