Board index
Login
RegisterI have two command buttons, buttonA and buttonB. buttonA is enable and buttonB is disable (it can enable based on some conditions. it is uses the disabled attribute in the p:commandButton tag) on the first time the page is load.
If I click on the buttonA (ajax call and will update buttonB) which will change some conditions on the server that will enable buttonB. After the ajax call return buttonB is enable as expected but if I pressed buttonB the action associated with buttonB is not invoke on the server side.
This was working in 2.2RC1 but does not work in 2.2RC2 and 2.2.
I believe this is a bug. Can this fix be in 2.2 maintenance release?
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
PrimeFaces Community Forum
Board index ‹ JavaServer Faces ‹ General ‹ Re-enabling a disable commandButton does not fire ajax call
12 Feb 2011, 10:52
14 Feb 2011, 07:32
14 Feb 2011, 11:39
15 Feb 2011, 07:57
15 Feb 2011, 10:18
15 Feb 2011, 10:18
16 Feb 2011, 06:50
17 Feb 2011, 03:44
22 Feb 2011, 06:37
Re-enabling a disable commandButton does not fire ajax call
14 posts
• Page 1 of 2 • 1, 2
12 Feb 2011, 10:52
What is the scope of your backing bean?
PrimeFaces Lead
14 Feb 2011, 07:32
I am using a request scope backing bean.
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
14 Feb 2011, 11:39
Mang
Just a thought. We had loads of Ajax issues with the new release when we went from RC2.2 to v2.2. After loads of hair pulling we solved our issues by making sure that our action contained faces-redirect=true. So for example on your action into your page with the ajax request on try:
action="/pagename?faces-redirect=true"
Give this a try if you have not already done so.
Regards
Steven
Just a thought. We had loads of Ajax issues with the new release when we went from RC2.2 to v2.2. After loads of hair pulling we solved our issues by making sure that our action contained faces-redirect=true. So for example on your action into your page with the ajax request on try:
action="/pagename?faces-redirect=true"
Give this a try if you have not already done so.
Regards
Steven
15 Feb 2011, 07:57
What do you mean by this?
action="/pagename?faces-redirect=true"
Here is my example xhtml which I use it to identify the problem. If I just add the action attribute to the existing p:commandButton, it does not fix the problem.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.prime.com.tr/ui">
<h:head>
</h:head>
<h:body>
<h:form prependId="false">
<p:commandButton id="submit" value="Submit"
actionListener="#{testWidgetsAM.invokeEnableButtonAction}" ajax="true" update="submit disableSubmit"/>
<p:commandButton id="disableSubmit" value="Disable Submit"
disabled="#{!testWidgetsAM.enable}" actionListener="#{testWidgetsAM.invokeDisableButtonAction}" ajax="true"
update="submit disableSubmit">
</p:commandButton>
</h:form>
</h:body>
</html>
action="/pagename?faces-redirect=true"
Here is my example xhtml which I use it to identify the problem. If I just add the action attribute to the existing p:commandButton, it does not fix the problem.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.prime.com.tr/ui">
<h:head>
</h:head>
<h:body>
<h:form prependId="false">
<p:commandButton id="submit" value="Submit"
actionListener="#{testWidgetsAM.invokeEnableButtonAction}" ajax="true" update="submit disableSubmit"/>
<p:commandButton id="disableSubmit" value="Disable Submit"
disabled="#{!testWidgetsAM.enable}" actionListener="#{testWidgetsAM.invokeDisableButtonAction}" ajax="true"
update="submit disableSubmit">
</p:commandButton>
</h:form>
</h:body>
</html>
15 Feb 2011, 10:18
Hi Mang
I was more refering to actually placing the redirect on to the link which takes you to the page which is causing the problem, however, it appears you only have one page which would not make any difference. One thing I have noticed is that you don't have a comma to separate your id's within the update attribute. Try this:
update="submit, disableSubmit"/>
I was more refering to actually placing the redirect on to the link which takes you to the page which is causing the problem, however, it appears you only have one page which would not make any difference. One thing I have noticed is that you don't have a comma to separate your id's within the update attribute. Try this:
update="submit, disableSubmit"/>
15 Feb 2011, 10:18
Try a viewscope bean.
PrimeFaces Lead
16 Feb 2011, 06:50
I am using Spring so by default it does not have view scope. I copy an implementation from the web but have some problem to get it to work.
Instead I used session scope which should not make much difference in this case. Using session scope works.
I spent some time debugging to find out why it should depend on the scope. On this simple example, I can not see why it should depend on the scope.
And here is what I found as shown below. In 2.2.1 it checks for if it is disabled (this check implies that I can get the previous state from the backing bean which also implies that the scope of the bean must be view or above). In my case a new backing bean will be created and the initial value is fetched which is false indicating that it is disable. Hence it will not create the ActionEvent. In 2.2RC1, the ActionEvent will be created because there is no check . This method is called during the apply request values phase.
Is this check really necessary?
In 2.2RC1
public class CommandButtonRenderer extends CoreRenderer {
@Override
public void decode(FacesContext facesContext, UIComponent component) {
String param = component.getClientId(facesContext);
if(facesContext.getExternalContext().getRequestParameterMap().containsKey(param)) {
component.queueEvent(new ActionEvent(component));
}
}
In 2.2.1
public class CommandButtonRenderer extends CoreRenderer {
@Override
public void decode(FacesContext facesContext, UIComponent component) {
CommandButton button = (CommandButton) component;
if(button.isDisabled()) {
return;
}
String param = component.getClientId(facesContext);
if(facesContext.getExternalContext().getRequestParameterMap().containsKey(param)) {
component.queueEvent(new ActionEvent(component));
}
}
Instead I used session scope which should not make much difference in this case. Using session scope works.
I spent some time debugging to find out why it should depend on the scope. On this simple example, I can not see why it should depend on the scope.
And here is what I found as shown below. In 2.2.1 it checks for if it is disabled (this check implies that I can get the previous state from the backing bean which also implies that the scope of the bean must be view or above). In my case a new backing bean will be created and the initial value is fetched which is false indicating that it is disable. Hence it will not create the ActionEvent. In 2.2RC1, the ActionEvent will be created because there is no check . This method is called during the apply request values phase.
Is this check really necessary?
In 2.2RC1
public class CommandButtonRenderer extends CoreRenderer {
@Override
public void decode(FacesContext facesContext, UIComponent component) {
String param = component.getClientId(facesContext);
if(facesContext.getExternalContext().getRequestParameterMap().containsKey(param)) {
component.queueEvent(new ActionEvent(component));
}
}
In 2.2.1
public class CommandButtonRenderer extends CoreRenderer {
@Override
public void decode(FacesContext facesContext, UIComponent component) {
CommandButton button = (CommandButton) component;
if(button.isDisabled()) {
return;
}
String param = component.getClientId(facesContext);
if(facesContext.getExternalContext().getRequestParameterMap().containsKey(param)) {
component.queueEvent(new ActionEvent(component));
}
}
17 Feb 2011, 03:44
I would like to know if this is bug. If it is will it be fixed?
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
22 Feb 2011, 06:37
I would really appreciate if someone could provide some feedback especially someone from Primeface so that I know what I need to do.
e.g.
find a way to by pass the problem using request scope
just use view scope which will reduce scalability (the least likely option to take. currently, all the backing beans are in request scope)
wait for a fix which means that I will stay on 2.2RC1 version
change the origin source code that I pointed out which I think cause the problem
don't use p:command button and look for alternative
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
e.g.
find a way to by pass the problem using request scope
just use view scope which will reduce scalability (the least likely option to take. currently, all the backing beans are in request scope)
wait for a fix which means that I will stay on 2.2RC1 version
change the origin source code that I pointed out which I think cause the problem
don't use p:command button and look for alternative
Thanks
Mang
Mojarra-2.0.3
Glassfish v3
primefaces-2.2
14 posts
• Page 1 of 2 • 1, 2