+ Start a Discussion
jhartjhart 

Cannot reference custom object via packaged controller extension

The Visualforce guide "Controller Extensions" section states:

Because this extension works in conjunction with the Account standard controller, the standard controller methods are also available.

However, this does not seem to work when the calling page is in the same package as the controller extension.

For example, I have a package custom object ( "i__Email__c" ) and a controller extension written for it ( "i.CtlEmail" ).

In a "target" org (where the package has been deployed - not the DE org where the package was written), I can create a unpackaged page that uses my custom object and its controller extension:

Code:
<apex:page standardController="i__Email__c" extensions="i.CtlEmail">
{!i__Email__c.i__Type__c} email, sent at {!sentAt}
<apex:outputText rendered="false" value="{!i__Email__c.i__Sent__c}"/>
</apex:page>

This page works fine - the "{!i__Email__c.i__Type__c}" reference calls the standard controller's "geti__Email__c()" method, and the "{!sentAt}" reference calls the extension's "getSentAt()" method (which relies on the i__Sent__c field, thus mandating the unrendered outputText field to force the standard controller to query for that field).


However, let's say that I want the above page to be part of my package.  So, back on my development org, I make a new (packaged) page which has exact same markup seen above.  It saves & runs just fine in the DE org.

Note that, post-save, the markup has been changed to remove the namespace references:

Code:
<apex:page standardController="Email__c" extensions="CtlEmail">
{!Email__c.Type__c} email, sent at {!sentAt}
<apex:outputText rendered="false" value="{!Email__c.Sent__c}"/>
</apex:page>


That makes sense in the context of Salesforce's default namespace treatment in DE orgs.


So, let's roll out a new package with our page and deploy it to our target org.

Problem - the deployed page doesn't work!

 
 
Note that its unpackaged twin, with the exact same code, still works fine.

The error mesage implies that our page is asking for 'i__Email__cStandardController.Email__c', but should be asking for 'i__Email__cStandardController.i__Email__c'.  However, there is no way to compile a reference like that in our DE org, because the namespace gets removed  when {!i__Email__c.Name} becomes {!Email__c.Name}.

We will workaround this bug by exposing our own version of the Email__c object and changing the page references to use that instead:

Code:
Email__c msg = null;
global Email__c getMsg() {
  if (msg == null) msg = [select .... ];
  return msg;
  }

-------------------------------------------------------------------------------

<apex:page standardController="Email__c" extensions="CtlEmail">
{!Msg.Type__c} email, sent at {!sentAt}
<apex:outputText rendered="false" value="{!Msg.Sent__c}"/>
</apex:page>

This isn't an ideal solution - it's not quite as "salesforcey" because we aren't using the built-in object accessor that comes for free with the standard controller (and whose query SOQL is derived on the fly from the page references - instead we have to hardcode our query).

Notes:

1.  I have the error (failing packaged page plus working unpackaged copy) reproducing in a DE org right now if Salesforce wants to take a look.

2. the page above is a "reduced" version of the real pages that exhibit this bug.  The real pages are more complex, but the basic gist is the same.




Message Edited by jhart on 11-25-2008 04:01 PM
jhartjhart
I opened support case #02204986 to track this issue.

DE org id is 00D70000000Jqpv

Reproducing org is 00D7000000099yO (also a D
E org, but this happens in production too).
ricardcabreraricardcabrera

I see that the post it's really old, but this is happening to us right now. We've a VF page working in dev, everything fine. When we put in a Package, it says that Name is not in the query, and throws an exception. What query??? We're only using the default controller, this doesen't make any sese, the standard controller should do the query for us.

 

Is it possible that Salesforce didn't fix this in 2 years? Did somebody manage to solve this issue?

 

I have no hope that anybody answers after 2 years, but I think it worth a try.

 

Thanks

jhartjhart

Ricard -

 

I can't recall if salesforce ever fixed this.  The case # is gone from my partner portal (I only show cases back to 2009), and the last correspondence I have regarding that case is:

 

A bug has been created for this issue.  Our developers are still
investigating the issue.  I trust your workaround of using the Global method
is still effective.  Please let me know if otherwise.

The workaround still exists in our codebase, and works fine for our purposes.  Hopefully you'll be able to do something similar, lmk if you'd like to dig into more detail.

 

-john

 

ricardcabreraricardcabrera

Thanks a lot for answering John. We're gonna use your workaround then, but I feel really disapointed this is happening after so many Salesforce realeases.

 

Thanks again!!

 

Ricard