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=31842>. 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=31842 [struts-faces] Simple JSF integration with Tiles ------- Additional Comments From [EMAIL PROTECTED] 2004-10-22 18:23 ------- Craig, Thanks for taking a look at the code. I suspected you would have some issues with it :-) I will do my best to answer your points. (Please excuse the lengthy response but I think it may help you to understand my difficulties.) Let me start by explaining why I am stripping the leading '/' char. My original URL is http://localhost/myap/tiles.faces.view.do. I have a Struts action that uses wildcard mapping for the pattern 'tiles.*'. This is a simple ForwardAction with a "wildcard" parameter of {1}. (Side note: I found this to be a easy way to bring up tiles directly if you don't need preprocessing with action. In any event, this keeps my test simple). I have a tiles definition of 'faces.view'. It uses a single layout with a header, footer and main. For simplicity's sake, the header and footer being included are straight jsp's. The main page is 'hello.jsp' and contains a faces text input and command button. I use a <h:form> tag with no action specified. The layout page being used is 'layout.faces' and contains my <h:view> tags with <h:subview> around each of my tiles inserts. If I do not strip the leading '/' as I am doing in my code, then the form's post action (as generated by faces) ends up being '/tiles.faces.view.do' (not sure about the .do part, my example is at work and I'm at home). In any event, when I click the submit button, I get http://localhost/tiles.faces.view.do without the name of the webapp ('myap'). When I strip the leading '/' I get http://localhost/myap/tiles.faces.view.do which is correct. My ultimate goal is to post back to 'myap/tiles.faces.view.do' so that the tiles takes care of layout before faces stuff is rendered. I haven't tested the path mapped way of using ActionServlet, but it does work with extension mapping. Path mapping would probably throw off things if we trim the '/'. I will try and run some tests later this afternoon. You are right about it probably not working in portlets. I don't have much experience with them although I believe they don't have HttpServletRequest. I agree that there is no special reason to use struts-chain. I just thought it would be cool to ultimately have different combinations of chains depending on the level of struts-faces integration you needed. We could focus on changing FacesTilesRequestProcessor for now if that would be your preference. The bottom line is that I think there's something to my idea of getting ViewHandlerImpl to modify the value returned by getActionURL. If we can get that class to return the correct URL then I think the problem is solved (as far as tiles goes.) The trick is how to communicate the correct URL to ViewHandlerImpl. The request was the only way I could come up with. I tried FacesContext but the one the ViewHandlerImpl gets is for layout.faces (not tiles.faces.view.do). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
