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
