Salesforce: JavaScript Remoting and Managed Packages
I love the crap out of JavaScript Remoting, but came across a small bug when wrapping up the code in a managed package. As many of you know when you create a managed package it prepends your code with a unique name to prevent code conflicting e.g. a page controller called “MyController” becomes “MyPackage.MyController” where “MyPackage” is the prefix you’ve chosen for your managed package.
The bug I’ve found is caused by the fact that the prefix isn’t applied to the JavaScript that calls your Apex Remoting methods i.e you might have an Apex method called “myMethod” which is called like so outside of a managed package environment:
MyController.myMethod(parameters, function(result, event) {
callback(result);
}, {escape: false});
Once you package up your code however this call will no longer work, and if you look in the debugging console of your browser you’ll find an error something like: “MyController is not defined”
This is because in the managed package environment “MyController” actually doesn’t exist but is now called “MyPackage.MyController”! @greenstork and others have come up with a solution for this and it looks something like:
[Edit] One of the Salesforce guys has given me a very neat workaround:
// Check if "MyPackage" exists
if(typeof MyPackage === 'undefined'){
// It doesn't, so create an object with that name
window["MyPackage"] = {};
MyPackage.MyController = MyController;
}
// All code only refers to MyPackage.Controller
MyPackage.MyController.myMethod(parameters, function(result, event) {
callback(result);
}, {escape: false});
I’ve posted a message on the forums about this issue and Salesforce is aware and is working on it. Now that’s great customer service!
As an aside I’d love to know how they’re going to solve this issue! It’s quite complex because their compiler needs to run through all of your JavaScript code (including any libraries you might have included) and try to figure out what code is actually making remoting calls, and prefix that exclusively! This is a new problem for managed packaging because for the first time they need to work on code that isn’t necessarily 100% part of their platform. This is further complicated because you can Zip your resources. An interesting challenge indeed...
The Silver Lining 
Nice post. I was actually contemplating moving some actionFunction stuff to JS remoting and this nugget of knowledge will totally help.
Jason
February 26, 2012 at 7:52 pm
That is odd because even in my DE org, I need to use namespace.controller.method() so my code is transferable now. I don’t need this workaround you are doing. It’s been this way for months ever since I started using Remoting. I don’t think I am doing anything different than you.
Scott Hemmeter
February 27, 2012 at 4:45 pm
Your DE org is your packaging org?
Wes
February 27, 2012 at 4:49 pm
Yes, my packaging org. Same in my patch orgs. My orgs are on NA7. Not sure if that makes any difference.
Scott Hemmeter
February 27, 2012 at 4:52 pm
Yeah that’s the difference then. My development process starts with several developers working on a code base (from github) that is in their respective DE orgs (not packaging orgs) – so their orgs aren’t aware of the namespace. The code is then promoted through a series of sandboxes (QA, UAT etc.) before reaching the packaging org and that’s where the namespace is first used. Patching org are aware of the namespace of course.
Wes
February 27, 2012 at 4:55 pm
Wow, Mr Fancy over there! 🙂 Yes, that’s the reason. I don’t know if that’s a bug, but just a side effect of your process. It would be nice if we could spin up related DE orgs (like a patch org, but more for your purpose) so you didn’t have to deal with that.
Scott Hemmeter
February 27, 2012 at 4:57 pm
I spoke to an SFDC guy in the forums and they said it’s a bug they’re working on. If you think about how the prefixing works automatically for VF code when moving between sandboxes it make sense for it to work for JS remoting.
Would be great to have more DE orgs that mirrored the packaging org, great idea 🙂
Wes
February 27, 2012 at 5:23 pm
Great post Wes, we used something similar in our case where we have to use the same remoting code with and without prefix i.e. in DE org, QA and packaging orgs. This solution is very neat though !
Abhinav Gupta
February 28, 2012 at 9:41 am
Great tip, thanks Wes. Lets just hope that a Salesforce “fix” doesn’t break this work-around. 🙂
CloudMike
February 28, 2012 at 10:22 pm
This truly excellent Wes. Saved my bacon 😛
Shoby Abdi
March 1, 2012 at 8:46 pm
If there’s one meat worth saving it’s bacon! 🙂
Wes
March 1, 2012 at 8:51 pm
Wes, Thanks for the post. I just ran into the same exact issue. A quick google of the issue and your post came up. You just saved me a ton of time. I appreciate it! Cheers!
@JohnDTheMaven
April 22, 2012 at 11:20 am
Salesforce is working on it. It should be ready by Spring ’14
Larry
May 4, 2012 at 2:02 pm
Summer ’12 will help address porting VF remoting client-side invocation from DE orgs to installed orgs.
cwallatx
May 21, 2012 at 7:06 pm
See http://developer.force.com/releases/release/Summer12/javascript+remoting+enhancement.
cwallatx
May 22, 2012 at 5:11 pm
[…] @WesNolte came with a nice solution to the problem, described here: https://th3silverlining.com/2012/02/26/salesforce-javascript-remoting-and-managed-packages/ […]
Visualforce Javascript Remoting,Namespace handling improvements in Summer’12 release | WikiCloud
October 30, 2012 at 4:15 pm