Sean
I've been trying the same thing (use struts for tiles and the rest jsf) here's what I've found in case it useful.
Myfaces has a tiles handler and seems to work okay, (see www.myfaces.org) . Not wanting to use myfaces for the core, as its a beta version, I just use the my faces components with standard sun jsf, which works great.
Oh i thought perhaps i can adapt the code in myfaces and get it working with sun's jsf. No such luck i'm afraid, I still need to look into the JSF source to identify the precise problem but it basically has none of attempting to change the externalContext.dispatch() once running. (externalContext.disatch() same as context.getRequestDispatcher(path).forward(request,response).
The same problem naturally occurs when using tiles support in spring.
I've thought about the struts-faces lib but i'm trying to hang on until a stable version comes out. I really like the way the jsp tiles handler works with myfaces, if I have any joy getting this working then I'll post how i did it (after looking at the jsf source).
Mark
On 19 Oct 2004, at 23:07, Craig McClanahan wrote:
One issue to beware of is a JSF restriction related to RequestDispatcher.include() -- which is what Tiles uses under the covers. Each included Tile has to be nested in an <f:subview> tag (either in the surrounding page, or inside each Tile). In the "example2" sample app, I put these in the layout because it was easier -- but they need to be one place or the other. Do you have them in your app?
I would tend to make sure your app works with the standard Struts and Struts-Faces environment (the way example2 does) before inserting struts-chain into the mix. Otherwise, you're totally on the bleeding edge trying to get this all integrated (since struts-chain is still quite experimental itself) -- although I'll happily cheer from the sidelines and apply any reasonable patches that you come up with :-).
Craig
PS: The posts to "layout.faces" are an artifact of what JSF thinks the view identifier is when it is processing the form component. TilesFacesRequestProcessor (in the standard struts-faces library) handles this correctly by specializing some of the behavior as compared to FacesRequestProcessor. I suspect you'll need to end up with a specialized version of the standard servlet-chain for this to work. It would be ideal if we could come up with one chain that would "just work" for Tiles and non-Tiles and JSF and non-JSF use cases ... but it wouldn't bother me to supply multiple "standard" chain definitions and made picking the right chain easy to configure.
On Tue, 19 Oct 2004 16:40:47 -0400, Sean Schofield <[EMAIL PROTECTED]> wrote:I am trying to get struts and jsf to play nice with each other. Right now, my only requirements are to have tiles supported. Most everything else will be handled through JSF.
I have looked at the struts-faces package, but most of it seems to be overkill for what I want. I would like to use struts-chain and slightly modify the default chain to handle this.
I have 95% of this working but there is one big problem. When I "submit" the resulting page, it submits to the "layout.faces" instead of "foo.do" (whose forward points to the definition that uses layout.faces as the layout.) I am assuming the issue is that I have a <f:view> tag on my layout page and this is where the action is being configured. I'm still hunting in the source to confirm this ...
My idea is to add a command to the "standard-servlet" chain that would handle this problem. I noticed in the struts-faces package that a HttpServletRequestWrapper is sometimes used. I tried wrapping the request using this but no luck.
Any ideas on how I can accomplish this?
TIA, sean
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
