Folks, I'm finding that with a test value of 1 minute expiry in web.xml the following code redirects to the given url immediately when the page is rendered:
<meta http-equiv="refresh" content="${pageContext.session.maxInactiveInterval};url=#{facesContext.externalContext.requestContextPath}/index.xhtml"/>
Any pointers would be appreciated.
The ${pageContext} is only available when you're using JSF on JSP. It seems that you're using JSF on JSP's successor Facelets as you're trying to redirect to a XHTML file. Facelets has totally no notion of a ${pageContext}. You should be using #{facesContext} instead. The session is then available by #{facesContext.externalContext.session}. However, Facelets offers a shorthand to get it: #{session}. The same for the #{request}.
So, this should do:
<meta http-equiv="refresh" content="#{session.maxInactiveInterval};url=#{request.contextPath}/index.xhtml"/>
Related
I'm using the OmniFaces FullAjaxExceptionHandler to display error pages. The error pages are shown correctly, but I'm having issues with the styling of those pages.
My application is using a template which has CSS classes defined on the body element. These classes are different for normal and error pages:
Normal page:
<h:body styleClass="main-body layout-compact">
Error page:
<h:body styleClass="exception-body error-page">
When the FullAjaxExceptionHandler processes an exception, a forward to the error page is performed (based on the <error-page> mechanism in web.xml). Apparently this does not rerender the <h:body> tag, because when checking the HTML output, I can see that the <body> tag still contains the CSS classes from the normal page (instead of the classes of the error page).
It seems that the content of the original <h:body> is replaced with the content of the error page <h:body> instead of just replacing the full <h:body>. I don't know if this is default JSF / FullAjaxExceptionHandler behaviour.
Is there any way to have the <h:body> rendered with the correct CSS classes? Moving the CSS classes away from <h:body> is not an option.
This is unfortunately "by design". JSF doesn't replace the entire document when performing ajax navigation, but it only replaces the children of individual <head> and <body> elements, leaving the parents untouched. This is done so for historical reasons; older Internet Explorer versions namely doesn't support replacing them altogether.
What I have done myself is to simply put the style into the <main> element instead. The <header> and <footer> are usually identical anyway in the final HTML output. Basically:
<html>
<head>
<title>...</title>
</head>
<body>
<header>...</header>
<main class="#{page.type}">...</main>
<footer>...</footer>
</body>
</html>
If you really need to have the <body class> modified, then your best bet is to do so via JavaScript embedded in the error page template.
<h:outputScript rendered="#{faces.ajaxRequest}">
document.body.className = "exception-body error-page";
</h:outputScript>
Note: #{faces} is only available since OmniFaces 2.5, if you're using an older version, use instead #{facesContext.partialViewContext.ajaxRequest}).
I created a JSF page with PrimeFaces components. The project runs fine, but the PrimeFaces UI look and feel is completely missing. I'm only noticing below message in server log:
One or more resources has the target of 'head' but not 'head' component has been defined within the view
What does this mean and how can I fix the PrimeFaces UI styling?
This means that you're using plain HTML <head> instead of JSF <h:head> in your XHTML template. The JSF <h:head> allows automatic inclusion of CSS/JS resources in the generated HTML <head> via #ResourceDependency annotations. PrimeFaces as being a jQuery based JSF component library needs to auto-include some jQuery/UI JS/CSS files and this really requires a <h:head>.
So, search for a
<head>
<title>Some title</title>
...
</head>
in your templates and replace it by
<h:head>
<title>Some title</title>
...
</h:head>
See also:
What's the difference between <h:head> and <head> in Java Facelets?
Unable to understand <h:head> behaviour
How to programmatically add JS and CSS resources to <h:head>
How to include another XHTML in XHTML using JSF 2.0 Facelets?
Facelets relies on XML namespaces to work with XHTML. How are HTML 4, and as far as I know, HTML 5 do not support namespaces. Also HTML 5 has some new elements that are not available in XHTML. Even HTML 4 and XHTML have some differences regarding elements and attributes they support.
The question is: Is it possible to render HTML 4/5 documents using Facelets? If so, how?
Since Facelets is a XML based view technology which eats and emits in essence XML markup, you cannot use it with a HTML4 doctype. The HTML4 doctype describes several elements which cannot be self-closing, like <link>, <meta>, <br> and <hr>. However, with XML you're forced to close them like <link/>, <meta/>, etc. So using a HTML4 doctype is absolutely not an option for Facelets (that is, when you respect the standards and/or fear the w3 validator, it will however work perfectly on the most if not all webbrowsers).
HTML5, on the other hand, allows XML markup. This is specified in chapter 3.2.2 - Elements:
Example:
<link type="text/css" href="style.css"/>
Authors may optionally choose to use this same syntax for void elements in the HTML syntax as well. Some authors also choose to include whitespace before the slash, however this is not necessary. (Using whitespace in that fashion is a convention inherited from the compatibility guidelines in XHTML 1.0, Appendix C.)
I myself use <!DOCTYPE html> all the way, also with JSF/Facelets, even without a <?xml?> declaration in top of the page. It works perfectly in all browsers. With a XHTML doctype you should as per the specification be using a Content-Type of application/xhtml+xml which would only make MSIE to choke (it doesn't understand it). And since that's still one of the most widely used browsers... Replacing the XHTML content type by text/html is considered harmful, you also don't want to do this.
As per your arguments:
HTML 5 do not support namespaces.
This doesn't matter. The namespaces are only of interest for the XML based server side view technology (like as Facelets) which in turn can generate pure HTML with those tags. The following example is legitimately valid for Facelets:
<!DOCTYPE html>
<html lang="en"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html">
<h:head>
<title>Title</title>
</h:head>
<h:body>
<h:outputText value="#{bean.text}" />
</h:body>
</html>
This renders legitimately valid HTML5 (for the client side):
<!DOCTYPE html>
<html lang="en">
<head>
<title>Title</title>
</head>
<body>
Some text
</body>
</html>
You see, Facelets already removes the XHTML declarations since they have no meaning in the client side.
And,
Also HTML 5 has some new elements that are not available in XHTML
this make also no sense. It's all about the generated output. Which can be HTML5 as good. Your only problem may be the browser support and the availability of 3rd party JSF components which renders HTML5 specific elements. Since JSF 2.2, it's possible to use the new passthrough elements feature to turn custom elements into a JSF component. Simply give the HTML5 element a jsf:id attribute. It'll transparently internally be interpreted as a UIPanel instance in the JSF component tree (like <h:panelGroup>).
<!DOCTYPE html>
<html lang="en"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
>
<h:head>
<title>Title</title>
</h:head>
<h:body>
<header jsf:id="header">Header</header>
<nav jsf:id="nav">Nav</nav>
<main jsf:id="main">Main</main>
<footer jsf:id="footer">Footer</footer>
</h:body>
</html>
You can even reference it from ajax as in <f:ajax render="main">.
Actually, XHTML is overhyped. Its sole intent is to ease HTML development using XML based tools which can manipulate/transform/generate HTML pages on the server side (like as Facelets). But some starters also use it without using any XML tool and output it plain as-is, because it's "so cool" -for some unclear reason.
Don't get me wrong. XHTML is great as server side view technology. But simply not as client side markup technology. It has utterly no value at the client side.
See also:
Our XHTML wiki page
How should a <!DOCTYPE> section look in JSF? HTML5 or XHTML?
JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used
On a related note, check out this IBM developerWorks article: JSF 2 fu: HTML5 composite components, Part 1
MyFaces has an extension for html5. Try this http://myfaces.apache.org/html5/
I've read, that this should be possible, but I did not do it myself, yet. Maybe you should just use HTML 5 inside the xHTML wrapper code. I will see, if I can find the source of information I've again.
[EDIT]
Seems like, there has been some work at MyFaces to support HTML5 rendering during Google's summer of code. I don't know if it should be used in a productive way, yet.
MyFaces Wiki
java-doc
Jazzon talk, download presentation
Jazzon talk, Exploring HTML 5 with JSF 2
Please give us a feedback, if you get it to work.
[/EDIT]
http://wiki.whatwg.org/wiki/HTML_vs._XHTML has some useful information on how namespaces can be used in HTML5 to assist migration from XHTML. Perhaps you can try applying the namespace as it suggests and see what occurs?
<a4j:ajax event="click" render="tempval" listener="#{question.setParameters}" />
When we are using this code, the server throws an exception with the message
#{...} is not allowed in template text
How is this caused and how can I solve it?
You will get this error when you're using JSP as view technology and you're using #{...} in template text such as (the <p> is just examplary, it can be any plain HTML element):
<p>#{bean.property}</p>
It's namely not supported in JSP, but it is supported in its successor Facelets. In JSP, you would need to explicitly use <h:outputText>:
<p><h:outputText value="#{bean.property}"></p>
However, in your particular code snippet wherein you're using #{...} in a JSF component already, that can only happen if the a4j tag library is not properly been registered as a JSP tag library by <%# taglib %>, or if the a4j tag library cannot be found in the classpath. This way the <a4j:ajax> tag is not parsed and thus treated as plain text, including all attributes with EL expressions. So the #{question.setParameters} is treated as EL in template text, which is not supported in JSP.
But your problem is bigger: the RichFaces 4.x component library, which the <a4j:ajax> is part of, does not support JSP. JSP is deprecated since JSF 2.0 and succeeded by Facelets. All JSF component libraries such as RichFaces have decided to drop support for JSP, because it's a hell of a lot of work to develop and support tag libraries and components for the two different view technologies JSP and Facelets. So even if you have RichFaces 4.x already in the classpath and you've properly registered it by <%# taglib %>, it would never work in JSP, simply because the JSP .tld file does not exist for the a4j namespace.
In order to use JSF 2.0 compatible component libraries, you've to migrate from JSP to Facelets. An alternative is to use the older RichFaces 3.x version instead. Version 3.3.3 supports JSF 2.0 on JSP. It offers the <a4j:support> tag to achieve the same. But keep in mind that you're going backwards in technology this way. You should keep moving forwards. Drop JSP and go for its successor Facelets.
See also:
Migrating from JSF 1.2 to JSF 2.0
Our Facelets wiki page - contains several tutorial links at the bottom
I faced the same problem, for me the cause of the error was a commented line in javascript that use #{...} to assign value to a field in my page.
once I removed it worked fine, sounds weird but this is what happened.
if you are using jsp as a view technology you need to import the below two libraries.
<%# taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%# taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
if you using xhtml add the below in html tag like
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:c="http://java.sun.com/jsp/jstl/core">
...
</html>
just remove the Xmlns from jsp page
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich">
and now add tag lib for jsp page..
<%#taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%#taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
It will definitely solve your problem.
See this.
When and why to use <h:head>, instead of <head>?
I've seen Primefaces won't work with <head>, though.
The <h:head> is a JSF component which provides a hook to programmatically include JavaScript and CSS resources in the generated HTML <head>. PrimeFaces uses it to include the necessary JS/CSS code for the Ajax works and fancy look'n'feel.
As a test, create a page with a <h:head> and a PrimeFaces component, open the page in the webbrowser and check the generated HTML source by rightclick - View Source. You'll see that several JSF and PrimeFaces specific JS/CSS files are been added. Now replace <h:head> by <head> and check the generated HTML source once again, you'll see nothing this time.
The <head> tag is a HTML tag, which defines the head of the HTML page (this is where you define metadata, or include the resources such as JavaScript or CSS for example).
The <h:head> is a JSF tag (introduced with JSF 2.0) that handles the <head> part of your page. The interest of having such JSF tag is that this head becomes part of your JSF components tree, and thus, you can manipulate it in your Java code.
Regarding the <head> incompatibility with Primefaces, I don't see why it happens. Facelets introduced in JSF 1.x the ability to mix HTML code and JSF (XHTML) code, and you should not have any trouble to insert a HTML <head> tag in your page, even if you use Primefaces. Facelets is natively integrated with JSF 2.x.