No, the servlet is the dispatcher. - Before the request, the filter adds a request attribute to say 'I'll handle the clean up'. - The servlet runs as normal, except if it finds this request attribute, it does not pop the action off the stack, nor clean up the dispatcher. - After the request, the filter pops the action off the stack, and cleans up the dispatcher.
Basically, no filter - things work just as they do now. With filter, your cleanup is postponed until when you want it (governed by your ordering of the filter chain). M On 29/7/03 1:54 AM, "Jason Carreira" ([EMAIL PROTECTED]) penned the words: > What does the filter do in this case? Does it become the whole > dispatcher? I thought you had a heated discussion with someone about why > that was a bad idea :-) > >> -----Original Message----- >> From: Mike Cannon-Brookes [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 28, 2003 10:14 AM >> To: [EMAIL PROTECTED] >> Subject: Re: [OS-webwork] Re: WW1.3 and Sitemesh >> >> >> I agree - there should be nothing in SiteMesh that affects this. >> >> What is wrong with the filter/servlet combination? It works >> perfectly, will allow SiteMesh usage with WW tags in the >> decorator (that's a 'nice' combination - no interdependency) >> and all WW apps will be backward compatible by just not using >> the filter? (filter only required for those who _want_ to use >> WW tags in a SM decorator) >> >> Mike >> >> On 28/7/03 9:43 PM, "Scott Farquhar" ([EMAIL PROTECTED]) >> penned the words: >> >>> How would you propose this work? >>> >>> I don't think that this should be put into sitemesh at all - it is a >>> *webwork* feature, and sitemesh should not have a dependency on >>> sitemesh at all. >>> >>> It can easily be done in webwork code, in a way that doesn't affect >>> anyone who chooses not to use it (apart from my email outlining how >>> this won't work with multiple applyDecorator tags). >>> >>> Cheers, >>> Scott >>> >>> Chris Miller wrote: >>> >>>> Updating all the taglibs etc to try to find it using >> STACK_HEAD as a >>>> last resort sounds a little messy, and is not required by a large >>>> percentage of WW users anyway. The current approach where WW >>>> publishes the value so post-webwork code can access it >> sounds fine. >>>> The real problem of course is that the feature isn't documented. >>>> >>>> I think the responsibility should be left with Sitemesh to >> push/pop >>>> this value. >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites >> including Data Reports, E-commerce, Portals, and Forums are >> available now. Download today and enter to win an XBOX or >> Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet > _072303_01/01 > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
