It's something that's perceived as a "known bug" by the dev community but it never made to the list...
Jeff Douglas has written this up together with viable workarounds in March 2010: http://blog.jeffdouglas.com/2010/03/04/passing-parameters-with-a-commandbutton/ (the post and comments also contain few useful links to SF message boards).
Simple fix is to use commandLink but style it to look like a button:
<apex:commandLink action="{!Pageredirect_new}" value="New" styleClass="btn" style="color:white;text-decoration:none">
<apex:param assignTo="{!account_name}" value="{!Account.name}" name="account_name"/>
</apex:commandLink>
Or (ab)use the fact that commandButton suddenly behaves as it should if one of it's side-effects will be a rerender of something (even of a region you don't care about).
<apex:commandButton action="{!Pageredirect_new}" value="New" rerender="hiddenBlock">
<apex:param assignTo="{!account_name}" value="{!Account.name}" name="account_name"/>
</apex:commandButton>
<apex:pageBlock id="hiddenBlock" rendered="false"></apex:pageBlock>
Last but not least, allow me to chip in my usual rant ;) Do you realize that you don't need an action method in your controller at all? Well, unless you have greatly simplified the code...
<apex:commandLink action="/a2A/e?CF00NK0000000cZqA={!Account.name}&CF00NK0000000cZqA_lkid={!$CurrentPage.parameters.id}" value="New" />
In fact you could go even further, if you'll realize you need immediate="true"
in this link then you might be better of with plain old <a>
tag...
If you'll keep such links in VF and not Apex they're much easier to modify later on (new fields, forgotten URLENCODE'ing etc) plus that's always couple lines less to cover with unit test ;)
You say you are having issues when deploying correct? Any chance the controller already exists in the org you are deploying to? Any chance you missed the controller in the new deploy?
One scenario I have run into in the past is that the validation Salesforce runs can be a bit tricky when dealing with controllers and Visualforce. For instance:
- You have two files in production, one for the controller and one for Visualforce.
- You make changes to both files in a dev org/sandbox.
- You deploy both files back to production, but validation fails on the Visualforce page. You get an error indicating a missing field, mismatched type, etc. indicating that the controller doesn't have that field.
- You verify both files work fine in dev and are completely confused at this point. The problem I have found is (and this is completely speculating but I have seen it before). The issue is that the production org is validating the Visualforce against the old Apex code before it deploys the updated Apex code as part of the deploy.
To workaround this issue, if you can, you need to either delete the production instance of the code or comment out the Visualforce as part of the deploy and then uncomment it in production. There is no exact science to it, and this may not even be the real reason behind my issues in the past, but I have experienced some very strange things during deploys in the past. Good luck!
Best Answer
One mechanism for doing this would be to pass the page controller instance as the parameter to the component and then the component can call the page controller's methods itself via that reference.
Here is a functional example:
Page Controller
Component Controller
Component Markup (TestComponent.component)
Page Markup (TestPage.page)