Rather than using tiles if you are using a JSP2 enabled server like tomcat 5.. You can use the JSP tag lib mechanism to use as a templating engine..
I've just tested using <f:view> and <f:subview> and all seems to work so far..
I created a tag file called template.
template.tag
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <html> <f:view> <body> <h1><h:outputText value="Header" /></h1>
<f:subview id="content"> <jsp:doBody /> </f:subview>
<h1><h:outputText value="Footer" /></h1>
</body> </f:view> </html>
And a jsp that is a subview.
in the jsp..
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib prefix="tags" tagdir="/WEB-INF/tags" %>
<tags:template>
<h1><h:outputText value="It WORKS!!!" /></h1>
</tags:template>I know its not as neat as tiles. But there have been so many problems with templating JSF (sitemesh doesn't play either).
This example also doesn't cover, different body parts that may need to be included.. But you could probably pass them in as attributes and workout what goes where that way.
Okay I'll shutup now as things have deviated from struts too far.
Mark
On 20 Oct 2004, at 10:21, Mark Lowe wrote:
Oh no.. Found it..
On 20 Oct 2004, at 10:17, Mark Lowe wrote:
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]
--------------------------------------------------------------------- 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]
