Passing Parameters with a CommandButton
March 4th, 2010
This post is a slight tweak of yesterday’s post, Passing Parameters with a CommandLink. In theory you should just be able to switch out the CommandLink component with a CommandButton component and be golden. However, not so fast. There seem to still be a bug with the CommandButton component.
Here is the Visualforce page with the CommandButton instead of the CommandLink:
1 2 3 4 5 6 7 8 9 10 11 | <apex:page standardController="Contact" extensions="CommandButtonParamController"> <apex:form > <apex:commandButton value="Process Nickname" action="{!processButtonClick}"> <apex:param name="nickName" value="{!contact.firstname}" assignTo="{!nickName}"/> </apex:commandButton> </apex:form> </apex:page> |
As with the CommandLink, when the user clicks the button the setters should fire and then call the processButtonClick() method to allow further publishing. However, the setter for nickName is never called!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | public with sharing class CommandButtonParamController { // an instance varaible for the standard controller private ApexPages.StandardController controller {get; set;} // the object being referenced via url private Contact contact {get;set;} // the variable being set from the commandbutton public String nickName { get; // *** setter is NOT being called *** set { nickName = value; System.debug('value: '+value); } } // initialize the controller public CommandButtonParamController(ApexPages.StandardController controller) { //initialize the stanrdard controller this.controller = controller; // load the current record this.contact = (Contact)controller.getRecord(); } // handle the action of the commandButton public PageReference processButtonClick() { System.debug('nickName: '+nickName); // now process the variable by doing something... return null; } } |
Wes Nolte has done a great job on his blog and the Salesforce.com message boards pointing out the problem and workarounds. A popular option is using the CommandLink but styling it to look like a CommandButton.
You can make the CommandButton function as advertised if you use a rerender attribute and hidden pageBlock component. If you run the Visualforce page below with these modifications the setter will actually fire and set the value of nickName correctly.
1 2 3 4 5 6 7 8 9 10 11 12 13 | <apex:page standardController="Contact" extensions="CommandButtonParamController"> <apex:form > <apex:commandButton value="Process Nickname" action="{!processButtonClick}" rerender="hiddenBlock"> <apex:param name="nickName" value="{!contact.firstname}" assignTo="{!nickName}"/> </apex:commandButton> <apex:pageBlock id="hiddenBlock" rendered="false"></apex:pageBlock> </apex:form> </apex:page> |
Categories: Apex, Code Sample, Salesforce, Visualforce
Yup, this is a classic bug. It should receive some type of Golden Bug Award for being so persistent. More than once have I forgot about it and then wonder why my markup wasn’t working,
http://community.salesforce.com/sforce/board/message?board.id=Visualforce&message.id=18750&query.id=275465#M18750
-Jason
Don’t use the assignTo=”{!nickName}”, but rather use: ApexPages.currentPage().getParameters().get(‘nickName’);
Andres, I think you might be a little confused. The assignTo does not reference the value of nickName but a method in the controller. Per the docs: “assignTo: A setter method that assigns the value of this param to a variable in the associated Visualforce controller.”
This is what I am saying:
And on the controller/extension, you do this:
ApexPages.currentPage().getParameters().get(‘nickName’);
This is what I am saying:
< apex:param name=”nickName” value=”{!contact.firstname}” />
And on the controller/extension, you do this:
ApexPages.currentPage().getParameters().get(‘nickName’);
Now I understand! Yes, that is another workaround. I look forward to this working as documented in the next release. Thanks for the info!
Andres’ workaround doesn’t work for me. The param from the button is not in the Page’s parameter map.
Thanks for the solution!
Thanks for this awesome post that’s still sadly applicable, even in Spring ’11. The three workarounds mentioned in your links and the above comments have been tremendously helpful.