role attribute of h:panelGrid - jsf

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.

Related

"rendered" attribute in "ui:fragment"

I want to use the rendered attribute in a ui:fragment to conditionally render a span element in my JSF 2.2 facelet. The JSF 2.2 documentation of ui:fragment lists rendered as an allowed attribute. I am using MyFaces 2.2.12 as JSF implementation, however, and the MyFaces 2.2 documentation of ui:fragment does not list rendered as a valid attribute.
I tried using rendered anyway, and it worked. However, my IDE - IntelliJ - rightly highlights the rendered attribute as an error and tells me it is not allowed in the ui:fragment element.
I saw a response in ui:fragment rendered attribute not working after upgrading Facelets to JSF 2 that there was a documentation bug where rendered falsly wasn't listed in the JSF 2.0 documentation, but the response says nothing about JSF 2.2 or MyFaces 2.2 (presumably because it dates before the release of JSF 2.2).
Is the missing rendered attribute in the MyFaces documentation also just a bug?
With multiple such occurances of the ui:fragment element in a single Facelets file, these "false" errors make finding real errors quite cumbersome. What is the recommended solution for this problem, if it really is just a bug in the documentation?
rendered is valid attribute in ui:fragment and ui:component in JSF 2.0, 2.1, 2.2. See JSF 2.2 View Declaration Language.
Some IDEs do not propose this attribute in autocomplete (content assistant) mode and validate it as "Unknown attribute". This happens because the rendered attribute was missing in the tag file declaration in JSF 2.0 (even if attribute was presented in the UIComponent) and the IDE validation is based on the tag file declarations. Issue was fixed in JSF 2.1: the missing attribute was added into the tag file declaration. Validation in IDE not always reflect to this change.

In NetBeans, Mojarra 2.2 outputStyleSheet doesn't have media attribute

I'm using NetBeans 8.0.2 and Mojarra 2.2 where according to the docs there's a media attribute and this is not the case, I get the following message:
The attribute media is not defined in the component outputStyleSheet
So the problem I know is with NetBeans 8.0.2. When I launch the application, It runs properly so does anyone know why NetBeans shows this error ?
It's documentary bug in the tag library declaration file of the Mojarra implementation. The Mojarra guys forgot to declare the media attribute of outputStylesheet tag in the html_basic.taglib.xml file. Netbeans is relying its tag/attribute validation on it and therefore gives false warnings.
The tag library declaration entry of the attribute is not necessary for the technical functioning of the attribute (not in components, tagfiles, nor composites) and that's why it just works fine.
The same documentary bug problem is known with below tag attributes:
<ui:fragment rendered> - fixed in Mojarra 2.1
<f:selectItem itemEscaped> - fixed in Mojarra 2.2
If you report the <h:outputStylesheet media> documentary bug, it'll likely be fixed in Mojarra 2.3.

What is an alternative of a4j:JsFunction in JSF 2.0?

I am new to JSF 2.0.
My current project is build on JSF 1.3 and Richfaces 3.3.
We are trying to migrate to JSF 2.0.
There is limitation to not use Richface 3.3 or 4.0 in Current Project or any third party tool/library. Our goal is to only use JSF 2.0 functionality/feature.
In my project there is lot of use of
<a4j:jsFunction data="action" oncomplete="JavaScriptFunction(data); >
<a4j:actionaram name="nm" assignTo="#beanName.methodName"> </a4j:actionparam>
</a4j:jsFunction>
I want to remove this type of a4j:jsFunction with h:commandButton or
any jsf 2.0 standard mechanism.
I am not able to find out best way to call Bean function which return some value and assign this return value to JavaScript function.
JSF 1.3? I thought 1.2 was the latest?
On to your question. The idea to only use JSF 2.x is invalid and you should have the decision maker reconsider because skimping on OmniFaces will impede your productivity and the general code quality.
The way I see it you have three choices:
OmniFaces
Click button with display:none using javascript. Said button can have f:ajax as a child
Rip o:commandScript http://showcase.omnifaces.org/components/commandScript it's open source.
I can fully understand that a company today says no to Primefaces or Richfaces and honestly I would recommend it for many applications. Omnifaces however is to be seen as a proper for JSF.

Migrating JSF 1.1 with Ajax4jsf 1.x to JSF 2

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

JSTL <c:remove not recognized

I have tried looking, and its just getting silly.
I am running Glassfish 3.1.1,
JSF version 2
and netbeans 7.0.1
And the following will not work, at all.
< html xmlns="http://www.w3.org/1999/xhtml"
xmlns:c="http://java.sun.com/jsp/jstl/core">
snipped
< c:remove var="test" scope="session"/>
I know it must be something stupid, this is what netbeans keeps saying:
The component library Jstl Core doesn't contain component
And in every JSTL tag library I have checked, it does!
The <c:remove> is originally in the JSTL library for the legacy JSP view technology. Facelets, the successor of JSP, has only a subset of the JSTL tags redefinied (JSP tags doesn't work in Facelets, they have been ported/rewritten). The <c:remove> is not among them.
Your concrete problem has to be solved differently. As the concrete functional requirement is unclear, I can't answer that in detail. But I guess that you actually need a JSF #ViewScoped or a CDI #ConversationScoped bean and store the desired property in there. It'll then be removed when the view scope or the conversation scope ends. Those scopes are well definied and lies in between the request and session scope. See also How to choose the right bean scope?

Resources