JSF templates

[Gina vernon]

Hi,
I am using facelets to template JSF views. The templates reference all the image paths and other relevant file paths. Due to this I am unable to create sub directories for the files calling the templates. for example:

folder 1
template1
page1_ _
|
|
folder2
page1

in the above dir structure, folder2,page1 will not render the template as the file paths in the template are relative to the folder in which the template resides which is folder1. I can add template1 to each sub folder, but that beats the purpose of templating.

Thanks.

[Greg Charles]

I've never had trouble with image links in templates, at least when using the JSF tags:

<h:graphicImage value="/images/myimage.png" />

That's going to look for an images/myimage.png in the application war as you'd expect.

However, I did have some trouble with links to stylesheets and such, so I had to go to the FacesContext:

<link href="#{facesContext.externalContext.requestContextPath}/css/template.css" rel="stylesheet" type="text/css" media="screen"/>

I'm not sure if that's ideal, but it worked for me.

[Gina vernon]

Greg, thanks a bunch for the solution. But this solution only worked with html components like img & link. I have a rich:panelMenuItem whose icon attribute does not read the EL expression #{facesContext.externalContext.requestContextPath}.

The source code shows this when comparing html component paths to rich faces component path. Let's say the contexpath is app:

HTML-app/folder/image.jpg
Richfaces-app/app/folder/image.jpg

Any thoughts?

[Greg Charles]

No, I don't really understand that. First of all, should shouldn't even need to worry about the context path in a rich tag, so something like:

<rich:panelMenuItem value="whatever" icon="/images/myimage.png" />

should work fine. Also, you say EL is not being evaluated for the icon attribute? That also doesn't make sense. EL should work for any attribute.

HTML-app/folder/image.jpg
Richfaces-app/app/folder/image.jpg

I'm not sure what you're showing us here. Can you show us both the tag the way you have it in your JSF, and then how it renders in HTML source?

[Tim Holloway]

The <link> element example that Rich supplied was raw HTML, not JSF. That's why the extra context information had to be added to the URL.

When using Facelet templates, relative URLs are relative to the resource path of the containing view definition, not the template's resource path.

Hope that helps, since I'm not 100% sure what the problem was, here.

[Greg Charles]

Tim Holloway wrote:The <link> element example that Rich supplied was raw HTML, not JSF.

It's just Greg and Gina here. No Rich, except in the tag names! Anyway, I agree that the JSF tags shouldn't need the context path, which is what I said in previous posts. Gina, have you made any progress here?

[Gina vernon]

Ok, hopefully I can explain this more clearly. I am actually a bit confused now.

Tim, says the paths are relative to the resource and not the template. If that's the case page1 and page2 will need two different paths which is not possible with a single template.

Here's my issue again:

The file/resource, which here is page2 in subfolder2, is referencing a template outside its directory. So the paths in the template are not relative to the resource, they are relative to the template.

Here's the dir structure again:

folder 1_ _ _
template1
page1
|
|
subfolder2
page2

Also, you say EL is not being evaluated for the icon attribute? That also doesn't make sense. EL should work for any attribute.

That came out wrong. The EL value is being evaluated but it evaluates to an incorrect path .
Context path in the source code page shows the path as 'app/app/folder/image.jpg' not 'app/folder/image.jpg',which is the correct path.

Here's the rich tag:

<rich:panelMenuItem icon="#{facesContext.externalContext.requestContextPath}/img/nav_swoosh.png" styleClass="panelMenuItem" 
        hoverClass="hoveredGroup" />

Here's the HTML:

<td class="rich-pmenu-nowrap rich-pmenu-item-icon rich-pmenu-top-item-icon "><img src="/pp/pp/img/nav_swoosh.png" alt="" width="16" height="16" id="leftIconsubNavform:j_id10" />

I have regular HTML tags like <img> and <link> in the template as well. They work fine from the either page.

[Tim Holloway]

Sorry, Greg, I'm incoherent at the best of times and morning isn't the best of times.

There are 2 options for URLs. And PLEASE NOTE that despite the superficial similarities, URLs are NOT resource paths, nor are resource paths URL fragments. They're 2 completely different things that just happen to look alike. And, depending on server capabilities, SOMETIMES act similarly.

The first options is a relative URL or resource path. In both cases, you can identify these because they don't begin with a slash. Or in the case of a URL, don't have an explicit protocol and server name in them. Or have only a protocol and so look like this: "http:./images/mypic.jpg". In other words, no double-slash after the "http(s):"

The second option is an absolute URL or path. For an absolute URL, the server name/port and webapp context paths are included. For an absolute resource name, the initial character is a slash character. Absolute is also dependent on context, since the root of a webapp is its top-level WAR directory, but the base of an external file resource is the root of the filesystem.

There is a "base" HTML tag that can be used to relocate the idea of where the base of an absolute URL is, but it doesn't get along that well with JSF. Struts, BTW has its own "base" tag to get around that.

There are 2 different bases for JSF URLs. One is the entire webapp URL, from, and including the context path on down. The other is the absolute location within the webapp, and its base is the root of the WAR. The second one applies to resource paths within the WAR or web-xml mappings (but that a whole 'nother can of worms!).

Raw HTML absolute URLs must always include the context path, since there's no way externally to tell how much of the URL is the context path part, even though 98% of the time, it's a single level.

JSF URLs that want to be nice to us, however, will provide the context path as part of their generated HTML output. Unfortunately, I'm not really sure that all JSF components are nice.

So, when setting up a template whose context path is something like WEB-INF/layouts/masterPage.xhtml, you can always find an image in the /images directory of the WAR by using the "absolute" URL "/images/mypic.jpg", regardless of what the directory structure of the invoking page view is. However, if you use a relative URL, the image location will be interpreted as relative to the location of the invoking view, not the template view. So absolute is the way to go. And, of course, don't use the raw HTML "img" tag, use the JSF image tag.

[Gina vernon]

Thanks, Tim! The absolute path worked perfectly.