This is indeed not going to work. You cannot pass “extra” parameters afterwards like that. The method-signature as you have declared has to be fulfilled in the side where the composite component is been used. E.g. <my:button action=”#{bean.remove(‘Somestring’)}” /> The composite component implementation should just look like this <h:commandButton value=”Remove” action=”#{cc.attrs.removeFieldAction}” /> If this is … Read more
True, JSP has some templating capabilities, but the biggest disadvantage of using JSP in JSF is that JSP writes to the response as soon as it encounters template text content, while JSF would like to do some pre/post processing with it. In JSF 1.0/1.1 the following JSF code <h:outputText value=”first”/> second <h:outputText value=”third”/> fourth would … Read more
Indeed, you cannot use the “good old” JSTL in Facelets anymore the way as you would do in JSP. Facelets only supports a limited subset of JSTL (and has it already builtin, the JSTL JAR file is in fact superfluous). You’re forced to write a custom tag or better, a custom EL function, for this … Read more
No, Facelets files are parsed to a XML tree using a SAX parser. The XML tree is stored in the Facelet cache. The XML tree is during view build time turned into an UIComponent tree which is accessible by FacesContext#getViewRoot() (which you can traverse by getChildren() during runtime). The component tree normally generates HTML code … Read more
The symptoms of the JSF components not being parsed at all indicates that the FacesServlet hasn’t run. This will happen when the request URL doesn’t match the url-pattern of the FacesServlet as definied in web.xml. This would mean that the actual url-pattern of the FacesServlet isn’t *.xhtml at all. Are you looking into and editing … Read more
No, the <f:event> is not strictly required to be placed inside <f:metadata>. It can be attached to any component. It’s indeed for pure self-documentary purposes placed inside the <f:metadata> whenever you have a bunch of <f:viewParam>s and would like to hook a <f:event> to invoke an action after all those view parameters have been set. … Read more
You need to create a custom ResourceResolver which resolves resources from classpath, put it in the common JAR file and then declare it in web-fragment.xml of the JAR (or in web.xml of the WARs). Kickoff example: package com.example; import java.net.URL; import javax.faces.view.facelets.ResourceResolver; public class FaceletsResourceResolver extends ResourceResolver { private ResourceResolver parent; private String basePath; public … Read more
The <h:outputScript> (and <h:outputStylesheet>) loads resources from /resources folder. You need to put the scripts in that folder. WebContent |– resources | `– js | |– jquery-1.6.2.js | |– myapp.validate.js | |– jquery.validate.js | `– jquery.maskedinput.js |– WEB-INF : Then the following script declarations should work: <h:outputScript name=”js/jquery-1.6.2.js” /> <h:outputScript name=”js/jquery.validate.js” /> <h:outputScript name=”js/jquery.maskedinput.js” /> … Read more
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 … Read more
During the JSF 1.0/1.1 ages this was indeed “not a good idea”, because all the HTML was not automatically taken in the JSF component tree when using JSP as view technology. All plain HTML was eagerly by JSP rendered before the JSF component tree. E.g. <p>Lorem ipsum <h:outputText value=”#{bean.value1}”> dolor sit amet<p> <p>Consectetur adipiscing <h:inputText … Read more