I use Icefaces and JSF and I have this problem:
I have the following url:
http://myMappedServer/myApp/followingThings
I would like to get in my xHtml page the value http://myMappedServer/myApp
How can I achieve this without using the managed bean?
Use EL: #{request.contextPath}.
It's quite useful for creating navigation links, to set in your main template a Facelets variable :)
<ui:param name="root" value="#{request.contextPath}/" />
UPDATE: It's not recommended to use the full path available in the app server because it's not guaranteed to be the same URL the user is using to access your app, so, beware of that.
If you really want, though, you can do that, using some methods available in HttpServletRequest to create an String like this:
#{request.scheme}://#{request.serverName}:#{request.serverPort}#{request.contextPath}
Related
I am using jsf 2. I have a link in a facelet file that points to a external url. My current view is /app1/home.xhtml with a h:commandLink that has an action like so
<h:commandLink value="#{link}" action="#{action.redirect}" target="_blank"/>
the url that action.redirect redirects to is /app2/info.do. However it appears that JSF tries to change the extension of the url to .xhtml. and then fails with the error message.
com.sun.faces.context.FacesFileNotFoundException: /app2/info.xhtml Not Found in ExternalContext as a Resource
how do i get this to correctly redirect ?
Don't use the <h:commandLink> here, it's the wrong tag for the purpose. It is designed to submit a JSF POST form and navigate to a JSF view, both which you obviously don't want to let take place in this particular use case.
Just use the <h:outputLink> or even plain HTML <a>. So,
<h:outputLink value="#{action.redirect}" target="_blank">#{link}</h:outputLink>
or
#{link}
Note that you don't need the <h:form> in both approaches.
In my JSF web-app, I want to create a URL for the user to bookmark or copy. That part is easy enough, like this:
<h:link value="Permanent Link"
outcome="/showStuff">
<f:param name="recID" value="#{bean.recordID}" />
</h:link>
Although that link has the desired parameter (recID) in it, it also has the windowid parameter generated by the JSF Servlet. Is there any convenient way to generate the URL without the windowid parameter? Or does this make any difference?
(This is with Mojarra)
You can remove the WindowId using a URLRewriteFilter framework such as OCPsoft Rewrite URLRewriteFilter
Doing something like this should be fairly straightforward using a single configuration rule. You can obviously fiddle if this rule is either too strict or too general.
.defineRule()
.when(Direction.isOutbound().and(
URL.matches("{prefix}{windowId}{suffix}")
.where("windowId").matches("windowId=[^&]+")))
.perform(Substitute.with("{prefix}{suffix}"))
Check out the rewrite site. It's pretty easy to set up. http://ocpsoft.org/rewrite/
I want to implement a navigation button that takes the user to another page. I have no desire or need for any validations to run nor for the model to be updated, etc. I have implemented this as an ajaxified client-side redirect (note, I am using Primefaces 3.2).
It works-- but is this the best way to do this?
Navigating from the "onePage.xhtml" to the "anotherPage.xhtml"
onePage.xhtml:
...
<p:commandButton value="Navigate to Another Page"
process="#this"/>
action="anotherPage?faces-redirect=true"
...
Note, I have tried using immediate="true", however Apply Request Values phase still runs, which results in a NPE for me in a getter in my managed bean (as I no longer have the data that my getter needs).
Just use <h:button> or <p:button>. It sends a normal GET request. There's really no need for a POST-Redirect-GET request if it's just page-to-page navigation.
<h:button value="Navigate to Another Page" outcome="anotherPage" />
For the PrimeFaces look'n'feel, just replace h: by p:. Note that this component doesn't require a <h:form>. The link equivalent is the <h:link> (for which there's no PrimeFaces equivalent, there's anyway nothing which needs to be restyled).
See also:
When should I use h:outputLink instead of h:commandLink?
Set attribute immediate to true on commandButton, this will skip all validations, conversions or updates. Attributes causes JSF lifecycle to jump from Apply request values phase directly to Render Response phase.
I have a misunderstanding with the use of flash scope in jsf 2.
I want to put an object in flash map during my action and show this object in the next page.
Here is my action (call by h:commandLink):
public String showDetail(PersonneDTO personne) {
MessageFlashBean message = new MessageFlashBean();
message.addMessage("test");
FacesContext.getCurrentInstance().getExternalContext().getFlash()
.put("test", message);
return "showDetail";
}
It's just a test, but the real object I want to use is more complex.
Here is the second page with the flash use:
<ui:fragment rendered="#{flash.test != null and flash.test.hasMessage()}" >
<ui:repeat var="message" value="#{flash.test.messages}">
#{message}
</ui:repeat>
</ui:fragment>
Here is the navigation (and here is my problem :) ):
<navigation-rule>
<from-view-id>/index.xhtml</from-view-id>
<navigation-case>
<from-outcome>showDetail</from-outcome>
<to-view-id>/private/showDetail.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
In this case, the flash scope works fine and my message appears.
But if I add a redirect in the navigation case, my object in the flash map has disappeared.
I don't understand why I can't use redirect in the navigation rule (I believed it was the goal of flash scope).
May be something is wrong in my code.
Someone can help me ?
Thanks
The Mojarra's implementation of the JSF2 Flash scope had a lot of problems. Most of them were resolved with every new Mojarra release. Currently, with the latest Mojarra version, the 2.1.6, there's as far as I know still only one major open problem: it won't work if you redirect to a different base path. See also the (currently) last comment in the long discussion in issue 1751.
Right now, you have basically the following options:
Forget using Flash when you need to redirect to a different base path. Use a request parameter instead or try to simulate the flash scope with a custom cookie.
If possible, reorganize the folder structure so that you don't need to redirect to a different base path when you need the flash scope to survive.
Try MyFaces instead of Mojarra. Maybe it does it better with regard to flash scope.
Update: as per issue 2136, the last open problem of Flash scope not being available after a redirect on a different path is solved in the shortly upcoming Mojarra 2.1.14. So with this version, all Flash scope related problems discovered and open so far
should be solved and closed.
jsf 2.1 with netbeans has this problem with flash. using /somepage?redirect-faces=true or /somedirectory/somepage?faces-redirect=true does not work. it has to be somepage?redirect-faces=true.
tested mojarra 2.1.7, but it didn't have the above problem.
I am not sure what are the benefits of using <f:view> and <f:subview>.
I noticed that one could write JSF pages without using them.
What are the benefits of using those tags?
<f:view>
The <f:view> is only useful if you want to explicitly specify/override any of the available attributes such as locale, encoding, contentType, etc or want to attach some phase listeners. E.g.
<f:view locale="#{user.locale}" encoding="UTF-8" contentType="text/html">
If you don't specify it, then the sane JSF defaults will just be used instead, which is respectively UIViewRoot#getLocale(), UTF-8 and the closest match of Accept request header. Noted should be that the closest match of Accept request header isn't always entirely right. Sometimes it results in application/xhtml+xml because of the presence of .xhtml extension in the URL in case of Facelets and the webbrowser not being configured to interpret it as text/html by default (like MSIE). You'd really like to avoid this wrong content type by explicitly setting it to text/html.
Note that it doesn't matter where you put it in the template. You can even put it in template client as immediate child of <ui:define>. However, canonical place is as immediate child of <html> and thus wrapping both <h:head> and <h:body>. This is also the way how it's done in legacy JSP where it's actually required. In Facelets it's optional and accounted as meta data.
See also:
Our XHTML wiki page
Is it possible to use JSF+Facelets with HTML 4/5?
JSF 2.0 not rendering any page
<f:subview>
The <f:subview> will create another naming container context. This is particularly useful when you want to reuse an include file which in turn contain fixed component IDs more than once in the same view root, otherwise you will get duplicate component ID errors. However, since JSF 2.0 such an include file can better be a composite component which is by itself already a naming container.
If you don't specify it, then it won't harm if you don't reuse a component with the same ID physically multiple times in the view.
See also:
Why <h:panelGroup> id is not found when I access through <f:subview> tag?
Binding attribute causes duplicate component ID found in the view
Difference between <f:subview> and <ui:composition> tags