3

I am developing a Visualforce page which will be rendered when a Salesforce User arrives by clicking a specific Account.

The Apex page looks something like this:

<apex:page> 

 <c:MyComponentToBeShownOnAccountView tab="Account" />

</apex:page>

After placing this component I am able to pick this Visualforce Page from Edit Account Layout in the org and drop it as a section which I currently use for development.

But After customer installed the Managed Package my Visualforce Page doesn't appear in Visualforce Page section of the Edit Account Layout.

I did a quick fix for now by adding standardController="Account".

Now fixed page looks like:

<apex:page standardController="Account"> 

 <c:MyComponentToBeShownOnAccountView tab="Account" />

</apex:page>

My Apex Controller class is implemented as a generic class which fetches the PageReference.get('id') of the page and finds the Custom Object through SOQL. So I am not inheriting the Account Controller and handling the Account request with a separate controller.

MyCompponentToBeShownOnAccountView class looks like:

<apex:component controller="GenericObjectHandleController">
...
...
</apex:component>

I am just confused why the first code shows up on Developer but not on Enterprise, and also whether this quick fix will work across all Types of orgs.

Should I re-implement the controller by the way Salesforce recommends?

Does the problem happened due to mismatch between versions of Developer and Enterprise org?

3
  • It's Visual force not Visual Source Aug 28, 2013 at 11:00
  • 2
    Normally a VF page as a section of a page layout is only possible when the page is using standard controller with the appropriate object type. This prevents silly implementation errors ensuring someone doesn't put a page for Lead on a Contact page layout and vice-versa. I'm surprised you were able to get it to work in your DE org, to be honest.
    – pchittum
    Aug 28, 2013 at 14:56
  • @Daniel Thanks. Corrected in appropriate places. Din't notice till you pointed out that its Force and not Source. Aug 28, 2013 at 15:11

1 Answer 1

4

You shouldn't be able to add a page to a layout without the standardController entity matching the layout's entity. It sounds like a bug in your DE org.

You should indeed use the standardController attribute on your page, and I would further recommend passing the standard controller to the component instead of grabbing the ID parameter. I use a class that looks (almost exactly) like this:

public with sharing class StandardController {
    public ApexPages.StandardController standardController { get; set; }
    public StandardController(ApexPages.StandardController standardController) {
        this.standardController = standardController;
    }
}

It's used in a page like this:

<apex:page standardController="Account" extensions="StandardController">
    <c:myComponent standardController="{!standardController}"/>
</apex:page>

Most of my components therefore use custom getter/setter methods, since it reduces my component's constructor to uselessness, but I consider it a worthy sacrifice, as I can then access the standard controller's PageReference's directly, such as cancel, view, and save.

public with sharing class myCompController {
    public ApexPages.StandardController controller {
        get; set {
            if(controller!=null) return;
            // do my component initialization here.
        }
    }
}

The standardController method works in all types of orgs. Not providing a standardController attribute is not supported and shouldn't work, so you should never rely on it working.

1
  • I think there is a bug in DE org. I couldn't replicate the same scenario in my partner DE org since I don't have Accounts enabled (creating a new case may resolve this). The above approach is much cleaner. Thanks Sep 6, 2013 at 6:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .