We Keep Coding

setting h:selectBooleanCheckbox value to false prevents commandButton oncomplete from being invoked

I am new to JSF and am working with an rich:extendedDataTable where one of the columns has an h:selectBooleanCheckbox as the header for select all purposes.
At the bottom of the table there is a a4j:commandButton (delete selected button) with an oncomplete action to launch a rich:popupPanel (confirm delete panel).
This all works fine, but when the table is refreshed, the select all checkbox remains checked after a delete is performed. In an effort to have it default to false when the table has been refreshed after a delete, I tried adding value="#{false}" to the checkbox. The problem is, when this value is set, my commandButton's oncomplete no longer gets invoked and is unable to show the pop-up panel.
I don't see the connection between the two, but maybe someone has an idea? Both the commandButton and extendedDataTable are within the same h:form For the time being, I am having my pop-up panel appear by using onbegin instead.
here is the code for my select all column.:
<rich:column id="modSelectColId" label="Selected">
<f:facet name="header">
<h:selectBooleanCheckbox id="selectAllId" onclick="selectAll(this)" value="#{false}"/>
</f:facet>
<h:selectBooleanCheckbox id="selectId" value="#{myBean.selectedMap[item]}" />
</rich:column>
here is the code for my command button:
<a4j:commandButton
value="Delete Selected"
oncomplete="#{rich:component('delSelectPopupId')}.show()" />

onShow event fires unnecessarily during each page reloading

I have an issue with making a menu in my project using Primefaces. Actually, this menu will get me a possibility to show some small dialogs with settings for the workspace (by clicking on menu items). Each dialog should have data lazy loading from database. Unfortunately, when I include my dialogs in the page (single xhtml file or a couple xhtml files with ui:include), an event onShow happens on each page reload and this is wrong and provoke too many unnecessary requests to the database.
Here is an example:
UI part
<h:form id="form1">
<p:menubar id="mainMenu">
<p:submenu label="Main menu" icon="ui-icon-document">
<p:menuitem value="My settings" onclick="mySettingsWv.show()" url="#" />
</p:submenu>
</p:menubar>
</h:form>
<p:dialog id="mySettingsDlg" header="My Settings" widgetVar="mySettingsWv" resizable="false"
closable="true" modal="true" showEffect="fade" hideEffect="explode" dynamic="true"
closeOnEscape="true" onShow="#{mybean.onShow()}">
<h:outputLabel value="Settings dialog" />
</p:dialog>
ManagedBean part:
#ManagedBean (name = "mybean")
#ViewScoped
public class MyBean {
public static Logger log = Logger.getLogger(MyBean.class);
public void onShow() {
log.info("Method onShow is being called on each page reloading, but dialog still has not been shown");
}
}
If I use action "onclick" for <p:menuitem> for manual calling the necessary method, it still executes it for each page reloading. Also if I try use actionListener, action attributes it don't work. <p:ajax> cannot be attached to <p:menuitem>.
What should I do in that case? What is wrong can be in my code?

Have a look at the primefaces documentation for p:dialog (same problem with p:menuitem and onclick). There the documentation says about onShow:
Client side callback to execute when dialog is displayed. (emphasis added)
That means that you can specify a javascript function there, but it does not work that way to specify a action on your backingbean which is called everytime the dialog is shown. What happens in your case is the following: #{mybean.onShow()} is evaluated only when the file is parsed (i.e. the p:dialog is rendered into the HTML) and then the value which is returned by the method is inserted there (i.e. the empty String).
To fix this you have to define a javascript callback which makes the call on the bean. You can do this by using p:remoteCommand:
<p:remoteCommand name="onShow" action="#{mybean.onShow}"
partialSubmit="true" process="#this"/>
And then specify this callback as the onShow attribute:
<p:dialog id="mySettingsDlg" ...
onShow="onShow()">

Prevent Double Submit on JSF Dialog AJAX CRUD

Just would like to know why do I encounter this behavior in my application.
I used primefaces for the UI and almost all of my pages follows this pattern. I heavily used AJAX in all of my CRUD
operations and using dialogs to show it to the user.
<ui:composition template="myTemplate.xhtml">
<ui:define name="content">
<ui:include
src="/pages/CreateDialog.xhtml" />
<ui:include
src="/pages/UpdateDialog.xhtml" />
<ui:include
src="/pages/DeleteDialog.xhtml" />
</ui:define>
</ui:composition>
My only concern is that, after doing CRUD stuff in my dialogs and user accidentally clicks F5 or refresh on the browser,
FF/Chrome and other browser always mentioned
To display this page, Firefox must send repeat action...
Obviously this will cause double submit. Previously I used Post-Redirect-Get in this scenario in older apps but since this
is AJAX JSF update then I cannot do this.
What's the workaround for this and is this normal? I thought AJAX actions should not trigger again during browser refresh.
Help?
UPDATE
I am opening my dialog with this code
<p:commandButton value="Add"
onclick="createWidget.show();"
update=":CreateForm"
action="#{MyBean.add}"
/>
My create dialog uses this
<p:dialog header="Create">
<h:form id="CreateForm" prependId="false">
<p:commandButton value="Add" icon="ui-icon-plus"
actionListener="#{MyBean.add}"
update=":messageGrowl"
oncomplete="closeDialogIfSucess(xhr, status, args, createWidget 'createDialogId')"/>
</h:form>
</p:dialog>
I actually am following the pages from this site...Full WebApplication JSF EJB JPA JAAS

Already experienced a few times that having JavaScript errors in callback methods ends up in such behavior. I was able to reproduce your problem which is disappeared after correcting the callback signature:
oncomplete="closeDialogIfSucess(xhr, status, args, createWidget, 'createDialogId')"
accordingly to you JavaScript function signature:
function closeDialogIfSucess(xhr, status, args, createWidget, dialogid)
(Sure if your JavaScript call has only 3 parameters then correct the oncomplete call)
Unrelated: I guess that you are using this function to close a specific dialog. Another way doing it would be assigning widgetVar attribute to your dialog:
<p:dialog id="testDialog" header="Create" widgetVar="createWidget">
<h:form id="CreateForm" prependId="false">
...
</h:form>
</p:dialog>
The widgetVar object will represent your dialog in the callback function so you can close it by call the hide() function of dialog:
function closeDialogIfSucess(xhr, status, args, createWidget) {
if(args.validationFailed || !args.loggedIn) {
jQuery('#testDialog').effect("shake", { times:3 }, 100);
} else {
createWidget.hide();
}
}

Ajax callback onstart works even if input is invalid

I have input fields and a command button inside an <h:form>. The input fields are required, and the validation error messages are showing well if something invalid is entered. At the end of the form, I have the following button:
<p:commandButton value="" ajax="true" update="foormm"
icon="ui-icon-check" actionListener="#{bean.sayHello}"
onstart="dialog.show()"
oncomplete="handleAjaxResponse(xhr, status, args)">
</p:commandButton>
The problem is, the dialog is showing regardless of validation. I thought the Ajax request was made iff inputs are validated. What's wrong here? Why does onstart get triggered even though the required fields are empty?
I use JSF 2.0, Primefaces 3.0 and Weblogic 12.1 with Eclipse.
Any help appreciated.

In other words, you want to show the dialog only when no validation errors have occurred after the postback? The onstart doesn't take that into account at all. It's invoked right before the ajax postback is invoked.
You'd need to approach it differently. The <p:dialog> has a visible attribute which can take an EL expression evaluating to a boolean outcome. You could make use of it:
<p:dialog id="dialog" visible="#{some condition}">
The #{some condition} can at its simplest be a combination of FacesContext#isPostback() and FacesContext#isValidationFalied(). So, if it's a postback and the validation has not failed, then the dialog should be visible.
<p:dialog id="dialog" visible="#{facesContext.postback and not facesContext.validationFailed}">
You just have to let your button update that dialog as well:
<p:commandButton value="" ajax="true" update="foormm dialog"
icon="ui-icon-check" actionListener="#{bean.sayHello}"
oncomplete="handleAjaxResponse(xhr, status, args)">
</p:commandButton>
Alternatively, you can also let the dialog's visible condition depend on some bean property which you set in the action(listener?) method:
<p:dialog id="dialog" visible="#{bean.saidHello}">

Is there a way to not sending a whole web form when click a button?

I will try to be as brief as possible, please stay with me here
"A.jsf" -> managed bean : bean
"#{bean.list}": will take us to B.jsf
<p:growl id="msgs" showDetail="true"/>
<h:form id="myform1" enctype="multipart/form-data">
<p:panel header="Upload" style="font-size: 11px;">
<h:panelGrid columns="2" cellpadding="10">
<h:outputLabel value="Drawing:" />
<p:fileUpload fileUploadListener="#{bean.handleFileUpload}" update="msgs" allowTypes="*.*;"/>
</h:panelGrid>
<p:commandButton ajax="false" immediate="true" id="back" value="Back" action="#{bean.list}"/>
<p:commandButton ajax="false" id="persist" value="Persist" action="#{bean.handleRevision}" />
</p:panel>
</h:form>
Then the handleFileUpload()
if(!upload){
FacesMessage msg = new FacesMessage(FacesMessage.SEVERITY_ERROR, "Error", "You do not have permission to upload.");
FacesContext.getCurrentInstance().addMessage(null, msg);
}
...
"B.jsf" -> managed bean: bean2
...
<p:growl id="msgs" showDetail="true"/>
...
When I click upload, it give me a growl error message "You do not have permission to upload.", which is good. But then when I click "Back", which will take me to B.jsf, I see the growl message "You do not have permission to upload." again. What seem to be happening is as I click the "Back", I send other form request to upload, which then generated the same error message, which then being displayed at B.jsf. Is there a way to fix this, beside putting the "Back" button into an empty form, because now I have two buttons standing on top of each others, instead of side by side. I try to do this:
FacesContext.getCurrentInstance().addMessage("tom", msg);
hoping that it would send to component with id="tom", so then the growl with id=msgs, would not get load, but no luck. I try to turn the upload flag on when I click the Back button, but the web form get requested before the method that handle the back navigation get called.
It is not as brief as I want it to be, therefore I want apologize for it :D

beside putting the "Back" button into an empty form, because now I have two buttons standing on top of each others
The HTML <form> is by default a block element. HTML block elements are by default been placed in a new line. You actually want to make it an inline element. You can do this using display: inline; in CSS.
Back to the actual problem, it however surprises me that the fileUploadListener method is called in spite of the immediate="true" in the p:commandButton. I tried to reproduce this and I can confirm this. But I wouldn't expect it to happen. Normally the immediate="true" on a button is the solution to skip submitting of the "whole" form (at least, skip the UIInput components without this attribute). Further investigation learnt me that the p:fileUpload isn't an UIInput component at all and that the listener is fired during apply request values phase instead of validations or update model values phase. So this behaviour is fully predictable, but imo still an oversight in the design.
Since the p:fileUpload requires ajax="false" on the p:commandButton component, you can on the other hand also just remove it from the back button so that it fires an ajaxical request and hereby skips the fileUploadListener being called.

Actually, putting the button in a different form sounds like an excellent solution. The reason the buttons don't align any more is that the new starting <form> element starts on its own line. You should be able to prevent this by adding form { display: inline; } to your CSS file.
That said, if you have some leftover error messages that you want to get rid of, you can do this in the initializing method of your backing bean (if you have one). The following works peachily:
public void clearErrorMessages() {
//it may get messy to debug why messages are swallowed
logger.debug("clearing messages, coming from " + new Exception().getStackTrace()[1]);
Iterator iter = FacesContext.getCurrentInstance().getMessages();
while (iter.hasNext()) {
FacesMessage msg = (FacesMessage) iter.next();
logger.debug("clearing message: " + msg.getDetail());
iter.remove();
}
}
The disadvantage here is that any errors that occur between submitting the form and initializing the backing bean of the target page are also swallowed.