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-08 10:30 ------- (In reply to comment #5) > 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. > Sounds ok to me. To help understand the need for a patch somehow let me explain though what it was needed for. The fix actually resulted from a disfunctioning we faced when integrating Tiles in a project using already Struts. The project used a personalization of the RequestProcessor which basically rewrote doForward() and doInclude() methods to fit some specific multi-inteface requirements. Integrating Tiles as it is simply broke up that personalization. View rendering just did not work any more. > 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. There is yet a missing step somewhere. > 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. In that case the border between "view rendering" and actual request processing is just not as clear as that. The problem we had to provide a patch for actually underlines that fact (see above). Maybe the solution you're pointed out is to implement the same mechanism in both places although that's functionality/code duplication and it does not convince me. Especially because it actually fails in the view rendering independency/ transparency in respect with some other architectural components somehow. So, in the case of a Tiles-Struts integration, I still believe that there is place for such a fix, certainly in different place. But it remains necessary to process includes in a consitent way with how they get processed by the Request Processor (here I'm talking of Tile-Struts integration, not Tiles standalone). So this may go in TilesUtilStrutsImpl. Basically what I'm saying is that in the case of Tiles-Struts integration the "include" mechanism used for the view rendering cannot ignore the "include" mechanism used in the RequestProcessor. -- 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]
