Re: Sitemesh buffering undecorated content

Mike,

I tend to agree, the mightDecorate() approach adds a reasonable amount 
of complexity for only a fairly modest gain (since often it would have 
to catch the response regardless) so I'm happy enough to bin that idea.

How do you see the exclude patterns working? Am I right in thinking we 
shouldn't add them to decorators.xml (even though I suspect most people 
intuitively would think they belong there?).

sitemesh.xml should probably look something like this:

<sitemesh>
   <page-parsers>
      <!-- default parser has been removed -->
     <parser content-type="text/html" class="...FastPageParser" />
   </page-parsers>

   <excludes>
     <pattern>/documents/*</pattern>
     <pattern>*.jpg</pattern>
     <pattern>*.gif</pattern>
   </excludes>

   <decorator-mappers>
     <!-- same as before -->
   </decorator-mappers>
</sitemesh>

Is there any particular feature you'd like to see the <excludes> pattern 
matching support?



Mike Cannon-Brookes wrote:
 > Chris,
 >
 > Good points all of them! I'm not sure about the mightDecorate() idea,
 > I'm more in favour of adding exclude patterns to sitemesh. I believe
 > in JIRA we already have a SiteMeshExcludeFilter which does pretty much
 > what you said (excludes certain paths from SiteMesh) - but it sounds
 > like something which should be in SiteMesh itself. It is often easier
 > to apply SiteMesh to /* and then add another exclude filter to *.pdf,
 > *.gif etc.
 >
 > That would be my preferred solution?
 >
 > Cheers,
 > Mike
 >
 > On Tue, 18 May 2004 00:17:39 +0100, Chris Miller
 > <[email protected]> wrote:
 >
 >>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
 >>[email protected]
 >>https://lists.sourceforge.net/lists/listinfo/opensymphony-sitemesh



-------------------------------------------------------
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