We're using a <a4j:commandLink ... /> with an action and render="#form". Since we've upgraded to Omnifaces 2.0 the action won't be invoked unless we replace #form with #this or an explicit id. The bean providing the action method is annotated with #javax.faces.view.ViewScoped.
Before with Omnifaces 1.8.1 it has worked well.
(We're using Java 8, JSF 2.2.6, Richfaces 4.5 and Wildfly 8.)
<a4j:commandLink id="#{cc.attrs.buttonId}"
action="#{cc.attrs.action}"
oncomplete="#{cc.attrs.oncomplete}"
onbegin="#{cc.attrs.onbegin}"
render="contentForm:contentSaveHandler contentToolbar #form"
execute="#this">
<h:outputText value="Test" />
</a4j:commandLink>
If I change #form to #this it works.
Related
How to update a div and do partial submission using <h:commandButton>, I have previously used <p:commandButton> to do partial submission by setting the ajax attribute to true and the update attribute to :statusBlock, where the id of the <h:panelGroup> is statusBlock. I am having some designing issues with <p:commandButton> so I cannot use it so I have to use <h:commandButton>.
This is to be done by nesting a <f:ajax> in it.
In effects,
<p:commandButton ... process="#form" update=":statusBlock" />
does exactly the same as
<h:commandButton ...>
<f:ajax execute="#form" render=":statusBlock" />
</h:commandButton>
Note that the subtle difference with the PrimeFaces equivalent is that PrimeFaces defaults to #form in the process/execute, while the <f:ajax> one defaults to #this, so you might need to explicitly specify execute="#form" over all place where you didn't specify the process attribute in the PrimeFaces component.
See also:
Communication in JSF 2.0 - Ajax (asynchronous) POST form
You can just use the standard components alongside f:ajax e.g.
<h:form id="myForm">
<h:commandButton value="Push Me">
<f:ajax execute="myForm" render="statusBlock" />
</h:commandButton>
<h:panelGroup id="statusBlock">
</h:panelGroup>
</h:form>
I'm using jsf1.2... and in order to use ajax... I've imported ajax4js jar
but somehow it's throwing error as unknown tag
<h:panelGroup style="padding-left:3px">
<h:commandButton id="submitVisaDetails"
value="Submit Request"
action="#{VtsIdAutogenerateBB.submitVisaDetails}"
onclick="return validateVisaEntries(this,this.form);"
styleClass="btn"
onmouseover="this.className='btn btnhov'"
onmouseout="this.className='btn'" >
<a4j:ajax execute="#form" />
</h:commandButton>
</h:panelGroup>
I hope that you are using Richfaces(ajax4jsf) 3 if so its not <a4j:ajax> its <a4j:support>. Ref: Ajax Support.
If you are using Richfaces 4 then its only supports JSF 2, so either upgrade to JSF 2 of use Richfaces 3.
I have some code that uses <h:outputText> to conditionally render groups of JSF elements. Examples:
<h:outputText rendered="#{authorization.admin}">
<h:outputText value="#{msgs.someinfo}" />
<h:inputSecret value="#{usermanager.password}" />
</h:outputText>
<h:outputText rendered="#{contactmanager.editAction}">
<li>
<label for="name"><h:outputText value="#{msgs.nameinfo}" /></label>
<h:inputText id="name" value="#{contactmanager.name}" />
<h:messages for="name" />
</li>
</h:outputText>
The code is on glassfish 2.1.1 which has the MANIFEST.MF in jsf-impl.jar looking like this (I'm not sure whether it actually uses this jar or some other one for JSF):
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_19-b02 (Sun Microsystems Inc.)
Specification-Title: JavaServer Faces
Specification-Version: 1.2MR2
Implementation-Title: Mojarra
Implementation-Version: 1.2_13-b01-FCS
Implementation-Vendor: Sun Microsystems, Inc.
Implementation-Vendor-Id: com.sun
Extension-Name: com.sun.faces
I'm trying to move to glassfish 4 which has some version of JSF 2 or higher.
All the hundreds of instances of this construct worked on the old glassfish, but they no longer work on the new one - they are replaced with nothing, regardless of what the rendered attribute evaluates to. Why?
Indeed, since JSF 2.0, children of UIInput and UIOutput are by default not anymore rendered. This is the consequence of fixes for issue 1154. In Mojarra 2.x, you can still turn it back on via a web.xml context parameter:
<context-param>
<param-name>com.sun.faces.allowTextChildren</param-name>
<param-name>true</param-name>
</context-param>
See also the Mojarra 2.0.0 release notes.
It's however more recommended to instead use <h:panelGroup> or <ui:fragment> for conditional rendering of blocks as the <h:outputText> is just the Wrong Tool™ for the job.
I have a Session Managed Bean where I have a list that I show in datatable and when I click in button I change the list in the managed bean but the table didnt change in the JSF page :
<p:commandButton id="someId" value="Button" action="#{gestionduplanning.exec2()}">
<f:ajax render="koka"/>
</p:commandButton>
<p:dataTable id="koka" var="op" value="#{gestionduplanning.listop}" style="width: 700px;float: left;">
<p:column headerText ="operateur" style="width:50px;" >
<h:outputText value="#{op.operateur.matricule}"/>
</p:column>
</p:dataTable>
How can I update the table in JSF and I need to keep my managed bean as session bean?
Remove <f:ajax render="koka"/> and add update="koka" to your <p:commandButton
<p:commandButton update="koka" id="someId" value="Button" action="#{gestionduplanning.exec2()}"/>
Also you better don't nest f:ajax with inside Primefaces components and vice versa...
f:ajax is meant to use with native JSF components
p:ajax is meant to use with PrimeFaces components
It is fine to have both , Primefaces components and JSF native components in one page, just make sure to use p:ajax in Primefaces components and f:ajax in JSF native components
First thing, you are using PrimeFaces, p:commandButton are already AJAX so you don't need f:ajax :
<p:commandButton id="someId" value="Button" action="#{gestionduplanning.exec2()}" update="koka" />
Other thing, make sure your data source (getListop()) is updated in the bean by exec2().
Refresh primefaces datatable using Java when clicking on the button.
DataTable dataTable = (DataTable) FacesContext.getCurrentInstance().getViewRoot().findComponent("formId:dataTableId");
dataTable.reset();
PrimeFaces.current().ajax().update("formId:dataTableId");
I have following code in jsf page, backed by jsf managed bean
<h:dataTable value="#{poolBean.pools}" var="item">
<h:column>
<f:facet name="header">
<h:outputLabel value="Id"/>
</f:facet>
<h:outputText value="#{item.id}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputLabel value="Start Range"/>
</f:facet>
<h:inputText value="#{item.startRange}" required="true"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="End Range"/>
</f:facet>
<h:inputText value="#{item.endRange}" required="true"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Pool type"/>
</f:facet>
<h:selectOneMenu value="#{item.poolType}" required="true">
<f:selectItems value="#{poolBean.poolTypesMenu}"/>
</h:selectOneMenu>
</h:column>
<h:column>
<f:facet name="header"/>
<h:commandButton id="ModifyPool" actionListener="#{poolBean.updatePool}" image="img/update.gif" title="Modify Pool">
<f:attribute name="pool" value="#{item}"/>
</h:commandButton>
</h:column>
</h:dataTable>
This code fragment is dedicated to editing come collection of items. Each row of the table contains "edit" button that submits changed values of the row to the server. It has the item itself as an attribute. Submit is performed by calling actionListener method in the backing managed bean.
This code runs correctly on Glassfish v 2.1
But when the server was updated to Glassfish v 2.1.1, the attribute stopped to be passed correctly. Instead of passing edited item (when we change the values in table row, we are actually changing the underlying object fields), the source item is submitted to server, i.e. the item that was previously given to the page. All the changes that were made on the page are discarded.
I tried to update jsf version from 1.2_02 to 1.2_14 (we are using jsf RI), but it had no effect.
Perhaps anyone came across the same problem? Any help and suggestions will be appreciated.
Glassfish ships with bundled JSF. Glassfish v2.1.1 ships with Mojarra 1.2_13. You actually don't need to have your own JSF libs in the /WEB-INF/lib. I am not sure how this particular problem is caused, but to start, you need to ensure that you don't have JSF version collisions in the classpath.
That said, the preferred JSF 1.2 way of passing bean properties is using f:setPropertyActionListener.
<h:commandButton id="ModifyPool" actionListener="#{poolBean.updatePool}" image="img/update.gif" title="Modify Pool">
<f:setPropertyActionListener target="#{poolBean.pool}" value="#{item}"/>
</h:commandButton>
Update: I recall something; this problem suggests that you still have a JSF 1.2 version older than 1.2_05 around in the classpath. Handling of component attributes has changed as per this version in favour of performance enhancements. In a nutshell, if you have a jsf-api.jar of older than 1.2_05 in your classpath, while there's a jsf-impl.jar of 1.2_05 or newer in your classpath, you will experience exactly this problem.
The solution is obvious: cleanup your classpath to get rid of the older JSF version. Paths covered by the webapp's default classpath are under each /WEB-INF/lib, Appserver/lib (which is in case of Glassfish somewhere in Appserver/domains/domainname/*) and the JRE/lib and JRE/lib/ext. Keep in mind that Glassfish's javaee.jar includes JSF libraries as well, so you really need to ensure that you don't have that JAR (or any other appserver-specific JAR file) in your /WEB-INF/lib or somewhere else.
You can add JBoss EL and write:
#{poolBean.updatePool(item)}
You don't need the whole Seam for that, works fine with JSF RI.
Probably it has to do with the way JSF 1.2 implements actionListener.
In JSF 1.1 and until recent implementations of JSF 1.2 (Richfaces, Trinidad etc) the order was setPropertyActionListener (or Attribute) -> actionListener -> action.
In JSF 1.2 and now implemented in Richfaces and Trinidad (not sure about IceFaces) the order is actionListener -> setPropertyActionListener (or Attribute) -> action.
I know it is disturbing and very annoying...
Who thought of it? What did they have in mind?
Anyway, try using an action instead of an actionListener and see if it works.