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] 2005-11-07 20:25 ------- OK I took another look at this and I am -1 on making the change you suggest. Firstly TilesUtilImpl would be the wrong place to do this, since that implementation (as per its javadocs) is intended for use without Struts - the correct place would be in either TilesUtilStrutsImpl or TilesUtilStrutsModulesImpl. The main reason I'm against this though is that IMO it is architecturally wrong and doing what you suggest would be against the contract of the RequestProcessor. The RequestProcessor performs a whole set of steps to process a request and just performing one of those steps would break its contract. If code was introduced into the RequestProcessors doInclude() method that relied on something that was done in a prior step it could cause your change to break. Also, tiles is only invloved in the "view rendering" portion of processing a request - having tiles invoke the RequestProcessor is the wrong way round, its the RequestProcessor that should (and does in the TileRequestProcessor) delgate part of its process to tiles. TilesUtil as its name implies is just a utility class and the only place the doInclude() method is called is in the InsertTag - and the functionality provided (including the content of a specified uri) is what is required. Thirdly, I believe TilesUtil has been designed so that its behaviour can be customized and any Web App can implement its own TilesUtil behaviour as a subclass of TilesUtilImpl and therefore we are meeting the goals that you desire. I think we should mark this as INVALID or WONTFIX. -- 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]
