Dooh.. The jsf source only provides the interfaces and abstract
classes, without the actual buts that do the work in there.
On 20 Oct 2004, at 09:59, Mark Lowe wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
