You need to realize that the <p:graphicImage> actually renders a <img src> element with just an URL which is then later individually invoked by the webbrowser when it’s about to parse the obtained HTML markup and present the results. So, whatever you do in the getter method of <p:graphicImage> it must be designed that way … Read more
The below procedure applies to JBoss AS 7.2+, JBoss EAP 6.1+, and JBoss WildFly 8+ and assumes that you’ve full control over the server installation and configuration. This upgrades the server-wide default JSF version: Download the individual Mojarra API and impl files (and thus not the single javax.faces.jar file). Current latest 2.1.x version is 2.1.29 … Read more
I think this may help: Get Request and Session Parameters and Attributes from JSF pages In fact, there should be a query: <h:outputText value=”#{param[‘id’]}” />
First of all, this (old) question and answer assumes JSF 2.0/2.1. Since JSF 2.2 there’s a native <h:inputFile> component without the need for 3rd party component libraries. See also How to upload file using JSF 2.2 <h:inputFile>? Where is the saved File? The easiest way would be using Tomahawk for JSF 2.0. It offers a … Read more
You need to nest <ui:param> inside <ui:include> to pass parameters to the included file. <ui:include src=”https://stackoverflow.com/questions/5291181/general.xhtml”> <ui:param name=”action” value=”actionOne” /> </ui:include> and in the include: <h:commandButton action=”#{action}” /> Note that this only supports strings, not action methods. For the latter you would need to upgrade to JSF 2.0 and use composite components.
Quote from chapter 6.1 of JSF 2.0 specification: FacesContext JSF defines the javax.faces.context.FacesContext abstract base class for representing all of the contextual information associated with processing an incoming request, and creating the corresponding response. A FacesContext instance is created by the JSF implementation, prior to beginning the request processing lifecycle, by a call to the … Read more
A straightforward approach would be the following view: <h:panelGroup id=”header” layout=”block”> <h1>Header</h1> </h:panelGroup> <h:panelGroup id=”menu” layout=”block”> <h:form> <f:ajax render=”:content”> <ul> <li><h:commandLink value=”include1″ action=”#{bean.setPage(‘include1’)}” /></li> <li><h:commandLink value=”include2″ action=”#{bean.setPage(‘include2’)}” /></li> <li><h:commandLink value=”include3″ action=”#{bean.setPage(‘include3’)}” /></li> </ul> </f:ajax> </h:form> </h:panelGroup> <h:panelGroup id=”content” layout=”block”> <ui:include src=”/WEB-INF/includes/#{bean.page}.xhtml” /> </h:panelGroup> With this bean: @ManagedBean @ViewScoped public class Bean implements Serializable { private … Read more
Ajax updating is performed by JavaScript language in the client side. All which JavaScript has access to is the HTML DOM tree. If JSF does not render any component to the HTML output, then there’s nothing in the HTML DOM tree which can be obtained by JavaScript upon Ajax update. JavaScript cannot get the desired … Read more
First of all, those starting with facelets. are not JSF context parameters, but Facelets 1.x context parameters. Previously, during JSF 1.x era, Facelets was not integrated as part of JSF. However, since JSF 2.0, Facelets is integrated as part of JSF, replacing legacy JSP as the default view technology, and most of the Facelets 1.x … Read more
That may happen if your webapp’s runtime classpath is polluted with multiple JSF impls/versions. The org.apache.myfaces entries in the stack trace tells that you’re using MyFaces. This problem thus suggests that you’ve another JSF implementation like Mojarra in the webapp’s runtime classpath which is conflicting with it. It’s recognizable by jsf-api.jar, or jsf-impl.jar, or javax.faces.jar. … Read more