DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35703>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35703 ------- Additional Comments From [EMAIL PROTECTED] 2006-01-27 17:39 ------- (In reply to comment #12) > Why does it break the contract of the RequestProcessor then would you ask ? > When it comes to Tiles (until version 1.2.x of Struts), i.e. integrating > Tiles > with Struts via Tiles Plugin, the application-specific TilesRequestProcessor > implementation is actually bypassed. You mean your TilesRequestProcessor.doInclude() is not called? And this is because TilesRequestProcessor does not override doInclude()? If that's the case I do not have a problem with modifying TilesRequestProcessor to override doInclude() and call super.doInclude(). But I still don't like the idea of a class calling a RequestProcessor hook directly. As Niall said before, those hooks are meant to be invoked in a chain by RequestProcessor, not individually by other components. It would be my preference if TilesRequestProcessor's doInclude() called a method in TilesUtil that could be overriden by application developers instead of TilesUtil calling TilesRequestProcessor.doInclude(). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
