I am using a datatable and for each row I have two buttons, an "Edit" and a "Delete".
I need these buttons to be read-only, i.e. disabled, if a certain condition is met for the row in question. I have seen in JSF 2 that it is possible to pass parameters to method calls. Is there anything equivalent in JSF 1.2?
Ideally what I would like it something like (the looping variable is loop and there is another bean, helper, which contains the method I would like to invoke):
<h:commandButton value="Edit"
disabled="#{helper.isEditable(loop.id)}" />
In this case it does not make semantic sense to add an isEditable attribute to the bean and it is not practical to create a wrapper Object around the bean.
Thanks in advance.
I have seen in JSF 2 that it is possible to pass parameters to method calls. Is there anything equivalent in JSF 1.2?
Passing parameters to method calls is not specific to JSF 2. It is specific to EL 2.2, which is in turn part of JSP 2.2 / Servlet 3.0 / Java EE 6. JSF 2 just happens to be part of Java EE 6 as well. In other words, if you deploy your JSF 1.2 web application to a Servlet 3.0 compatible container like Tomcat 7, Glassfish 3, etc and your web.xml is declared conform Servlet 3.0 spec version, then it'll just work out the box for JSF 1.x as well.
If you're however still targeting a container of an older Servlet version, then you need to supply a different EL implementation which supports invoking methods with arguments. One of those implementations is JBoss-EL which you can install by just dropping the jboss-el.jar file in /WEB-INF/lib of your webapp and adding the following context parameter to the web.xml. Here's a Mojarra-specific example (Mojarra is the codename of JSF RI):
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
If you're using MyFaces as JSF implementation, you need the following context parameter instead:
<context-param>
<param-name>org.apache.myfaces.EXPRESSION_FACTORY</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
See also:
Invoke direct methods or methods with arguments / variables / parameters in EL
Related
I started using JSF 2.0 with Facelets recently and got puzzled by new composite components knowing existing <ui:include> and other templating techniques offered by Facelets 1.x.
What is the difference between those approaches? Functionally they seem to offer about the same: <ui:param> vs <cc:attribute>, <ui:insert>+<ui:define> vs tag files, reuse of the existing templates. Is there anything besides syntax and clear interface specification in case of composite components? Could performance differ?
What is the difference between those approaches?
Facelet templates
Use Facelet templates (as in <ui:composition>, <ui:include> and <ui:decorate>) if you want to split main page layout fragments into reuseable templates. E.g. header, menu, content, footer, etc.
Examples:
How to include another XHTML in XHTML using JSF 2.0 Facelets?
What is the real conceptual difference between ui:decorate and ui:include?
How to customize h:head when using ui:composition template?
How to change head elements of a page when using ui:composition
How to ajax-refresh dynamic include content by navigation menu? (JSF SPA)
Facelet tag files
Use Facelet tag files if you want to have a reuseable group of components in order to prevent/minimize code duplication. E.g. a group of label+input+message components. The major difference with composite components is that the output of a Facelet tag file does not represent a single UIComponent and may in some circumstances be the only solution when a composite component doesn't suffice. Generally, having an <ui:include> with one or more <ui:param> which passes a managed bean property (and thus not a hardcoded value) is a signal that the include file can better be a tag file.
Examples:
How to create a custom Facelets tag?
How to make a grid of JSF composite component?
How to create a composite component for a datatable column?
Primefaces outputLabel for composite component
Composite components
Use composite components if you want to create a single and reuseable custom UIComponent with a single responsibility using pure XML. Such a composite component usually consists of a bunch of existing components and/or HTML and get physically rendered as single component and is supposed to be bound to a single bean property. E.g. a component which represents a single java.time.LocalDate property by 3 dependent <h:selectOneMenu> components representing day, month and year, or a component which combines <p:fileUpload> and <p:imageCropper> into a single <my:uploadAndCropImage> referring a single custom com.example.Image entity as property.
Examples:
Our Composite Component wiki page
The BalusC Code: Composite Component with multiple input fields
Split java.util.Date over two h:inputText fields representing hour and minute with f:convertDateTime
Select all items in Multiple SelectManyCheckBox with dynamic ids
Extending JSF commandLink component
Avoiding duplicate ids when reusing facelets compositions in the same naming container
Custom components
Use a custom component whenever the functionality cannot be achieved with Facelet tag files or composite components, because of the lack of support in the standard/available set of components. Generally when you want a high degree of control and/or customization of the decoding and/or encoding, and also to offer the endusers the possibility to relatively easily extend/override the decoding and/or encoding. Examples can be found over all place in source code of open source component libraries such as PrimeFaces and OmniFaces.
Tag handlers
When you want to control the building of the JSF component tree instead of rendering of the HTML output, then you should use a tag handler instead of a component.
Examples:
Custom Facelet component in JSF
How can I access the content of something created with <ui:define> programmatically?
Conditional render in tagfile depending on whether the attribute is specified or not
Performing a redirect, when conversion / validation associated with query parameters fails
Example projects
Here are some example projects which utilize all of above mentioned techniques.
Java EE Kickoff App (templates - includes - tagfiles - composite)
OmniFaces Showcase (templates - includes - tagfiles - composite)
Could performance differ?
Technically, the performance concern is negligible. The choice should be made based on the concrete functional requirements and the final degree of abstraction, reusability and maintainability of the implementation. Each approach has its own well definied purpose and limitations.
Composite components do however have a significant overhead during building/restoring of the view (specifically: during saving/restoring the view state). And, in older versions of Mojarra, composite components had performance issues with assigning default values, this is already fixed since 2.1.13. Also, Mojarra had a memory leak when a <cc:attribute method-signature> is used for method expressions, basically the entire component tree is re-referenced in HTTP session, this is fixed since 2.1.29 / 2.2.8. The memory leak can be bypassed in older 2.1 versions as below:
<context-param>
<param-name>com.sun.faces.serializeServerState</param-name>
<param-value>true</param-value>
</context-param>
Or in older 2.2 versions as below:
<context-param>
<param-name>javax.faces.SERIALIZE_SERVER_STATE</param-name>
<param-value>true</param-value>
</context-param>
Still, when you have relatively "a lot of" composite components, and you have javax.faces.STATE_SAVING_METHOD set to client, then the performance will be a pain. Do not abuse composite components if you merely want the basic functionality which is already possible with a simple include file or tag file. Do not use the ease of configuration (read: no *.taglib.xml file needed) as an excuse to prefer composite components over tag files.
When using Mojarra 2.2.10 or older, do not forget to disable the relatively short Facelets refresh period for production mode:
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>-1</param-value>
</context-param>
Do not use this setting for development, otherwise you've to restart the whole server to get changes in Facelets files to be reflected! Mojarra 2.2.11 and newer, and MyFaces already defaults to -1 when javax.faces.PROJECT_STAGE is not set to Development.
I'm using exaples from the official Java EE tutorial In which contains the follow:
<h:panelGrid columns="2"
headerClass="list-header"
styleClass="list-background"
rowClasses="list-row-even, list-row-odd"
summary="#{bundle.CustomerInfo}"
title="#{bundle.Checkout}"
role="presentation">
But compiler says that attribute role is not defined for h:panelGrid component. How to fix this?
That attribute was introduced in JSF 2.2. As evidence, the role attribute is mentioned in JSF 2.2 <h:panelGrid> documentation, but not in JSF 2.1 <h:panelGrid> documentation.
Your question history confirms that you're using JSF 2.2 on GlassFish 4.0, so this compiler warning is actually wrong. This is not exactly a JSF problem, but an IDE problem. The IDE is somehow thinking that you're not using JSF 2.2, but JSF 2.1 or older. I.e. your toolset is working against you. You didn't mention which IDE you're using, so it's not possible to post the right answer.
If the project runs fine and the JSF page produces the right HTML output (i.e. the role attribute actually ends up in generated HTML <table> element as you can see by rightclick, View Source in webbrowser), then everything is well and it's just the IDE who's pretending to be smarter than it actually is.
I'd start peeking around in IDE project's properties to check if the JSF versions are all right. The JSF facet in project's properties must be set to version 2.2, not lower. The faces-config.xml must be declared conform JSF 2.2, not lower.
We are migrating JSF 1.1 (MyFaces) project to JSF 2. The idea is to migrate periodically by keeping both JSP and XHTML together for some time. We use many ajax4jsf-1.1.1 tags in JSP pages. We don't use RichFaces. After configuring the system to JSF 2 (with all config changes mentioned in tutorial by Balusc) When tried to access the JSP page with ajax4jsf.jar in classpath, we get an exception:
Caused by: java.lang.IllegalStateException: setViewHandler may not be executed after a lifecycle request has been completed
at org.apache.myfaces.application.ApplicationImpl.setViewHandler(ApplicationImpl.java:853)
at org.ajax4jsf.framework.ajax.InitPhaseListener.beforePhase(InitPhaseListener.java:92)
at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:76)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:131)
It looks ajax4jsf.jar is not compatible with JSF 2. Looks some issue with LifeCycle configuration.
Is there any way we can make a4j work with JSF 2 JSPs? I know when we use XHTML we don't need all this.
Get rid of Ajax4jsf 1.x altogether. It's indeed not compatible with JSF2. Instead, JSF2 offers a new main ajax tag <f:ajax> which covers all the core functionality as previously offered by Ajax4jsf 1.x.
If upgrading to RichFaces 4 is not an option (because, as you said yourself, you aren't using RichFaces components anywhere), then just remove Ajax4jsf 1.x and replace all <a4j:xxx> tags by standard JSF2 equivalents.
<a4j:ajaxListener>: use <f:ajax listener>.
<a4j:keepAlive>: just put managed bean in the view scope by #ViewScoped.
<a4j:log>: use jsf.ajax.addOnEvent() or jsf.ajax.addOnError() in JS context.
<a4j:commandLink>: just nest <f:ajax> inside <h:commandLink>.
<a4j:outputPanel>: use <h:panelGroup> and remember to include its ID in <f:ajax render> or PrimeFaces <p:outputPanel>.
<a4j:repeat>: just use standard <ui:repeat>.
<a4j:form>: just use <h:form>, it will autorecognize <f:ajax>.
<a4j:htmlCommandLink>: just nest <f:ajax> inside <h:commandLink>.
<a4j:jsFunction>: just use standard <h:commandScript>. It was however introduced late in JSF 2.3. If you can't upgrade to JSF 2.3 then consider OmniFaces <o:commandScript> or PrimeFaces <p:remoteCommand>.
<a4j:region>: just use <f:ajax execute>, you can even wrap <f:ajax> around a group of components.
<a4j:loadBundle>: just use standard <f:loadBundle>.
<a4j:status>: use jsf.ajax.addOnEvent() or jsf.ajax.addOnError() in JS context.
<a4j:actionparam>: just use standard <f:param>.
<a4j:loadScript>: just use standard <h:outputScript>.
<a4j:mediaOutput>: no replacement. Consider PrimeFaces <p:media>.
<a4j:poll>: no replacement. Consider OmniFaces <o:commandScript> or PrimeFaces <p:poll>.
<a4j:commandButton>: just nest <f:ajax> inside <h:commandButton>.
<a4j:include>: just use standard <ui:include>.
<a4j:loadStyle>: just use standard <h:outputStylesheet>.
<a4j:support>: just use standard <f:ajax>.
You also need to rename/rewrite JSP files to Facelets files. In simple cases, this is usually just a matter of changing root declarations and file extensions. Facelets makes it easier to replace all duplicated code by a single template. The following answer applies:
Migrating from JSF 1.2 to JSF 2.0
i have a context param as follows:
<context-param>
<param-name>myInitParam</param-name>
<param-value>myValue</param-value>
</context-param>
i want to get an init param in JSF 1x (exact version is 1.1.02) as follows:
<object>
<param name="HTTPPort" value="#{initParam.myInitParam}" />
but i am getting the compiler error in JSP:
the attributes for a standard action or an uninterpreted tag cannot be deferred expressions
please advise how to get init param in JSF 1x, and what is the reference for EL used in JSF 1x.
The EL variable is correct, but you can't use deferred EL #{} in template text in legacy JSP which is the default view technology in JSF 1.x. This is exactly what the error message is trying to tell you.
You need to print it using a <h:outputText>.
<f:verbatim><param name="HTTPPort" value="</f:verbatim><h:outputText value="#{initParam.myInitParam}" /><f:verbatim>" /></f:verbatim>
(note that I assume that you were already emitting plain HTML using <f:verbatim>)
Yes, that's one line of ugliness, but that's the payoff of using JSP and one of the main reasons why Facelets was introduced.
See also:
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
I would like to display a text in jsf screen by passing an attribute to a method implemented in backing bean. I have to pass a dynamic value as an attribute. I tried the below but it seems to be an incorrect syntax -
<h:outputText value="#{getValue(#{item.product}).component.address}" />
Apart from the syntax error (you can never nest EL expressions like as #{#{}}), the following is valid in EL 2.2 which is in turn part of Servlet 3.0 / Java EE 6:
<h:outputText value="#{bean.getValue(item.product).component.address}" />
So if you have a Servlet 3.0 compatible target runtime (Tomcat 7, Glassfish 3, JBoss 6, etc) with a Servlet 3.0 compatible web.xml, then you can invoke non-getter methods with arguments like this.
However, based on your question history you're using JSF 1.2 and the chance is big that you're also targeting an older container where the above wouldn't work. If it is a Servlet 2.5 container, then you could use JBoss EL to get this EL syntax to work.
See also:
Invoking methods with parameters by EL in JSF 1.2
JSF 1.2 w/ EL 2.1 (the usual pairing) doesn't support calling methods with parameters on beans using EL expressions.
There exists one hack, abusing the fact that JSF EL expressions work on maps:
value="#{myBean['product']}"
This will assume myBean is implementing Map interface and will call get method with 'product' as parameter. I don't know if the key can be dynamically computed but it's worth a try.
Syntax would be:
value="#{myBean[item.product].component.address}"
Assuming here that myBean implements Map interface and returns the appropriate object and item.product is returns a string.
I am not sure this will work, but it's your only option beside implementing a getter that looks up item.product value in its implementation.