Re: Sitemesh buffering undecorated content

Yeah I think we can improve on the current inclusive-only filter 
url-patterns. I somehow manange to find myself in situations all the 
time where I kick, curse & scream because I can't exclude a path or two. 
I feel you shouldn't have to structure your directories a certain way 
just because of a Sitemesh (well OK, Servlet spec ;-) limitation.

The reason decorators.xml doesn't quite work (and please correct me if 
I'm wrong since I'm not 100% sure about this) is that decorators.xml is 
in fact specific to ConfigDecoratorMapper. It's quite possible that 
someone doesn't even have ConfigDecoratorMapper specified in 
sitemesh.xml, and besides quite a few of the Mappers ignore the path 
mapping completely (eg PageDecoratorMapper, CookieDecoratorMapper, ...) 
and do their own thing based on the contents of the request and/or page 
object. We need to decide not to decorate before the page object is 
created (this was my original motivation for the mightDecorate() approach).

Mike suggested via email that we could just add another filter that does 
the exclusions (it would just set FILTER_APPLIED). Tempting because it's 
a very simple fix! Seems a bit clunky to have two filters for Sitemesh 
though.




Hani Suleiman wrote:
> Hm, the way I deal with this is to only specify the filter on the resources
> I care about (eg, *.action, *.jsp, *.html). Although I spose that isn't good
> enough as the filter url's are inclusive rather than exclusive, so aren't
> expressive enough.
> 
> So yeah, +1 for adding exclusions to sitemesh.xml, with same syntax and
> rules using PathMapper. What's the argument to throw at people who will one
> day ask why they can't specify it in decorators.xml again?



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