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:
[code language=”javascript”]
MyController.myMethod(parameters, function(result, event) {
callback(result);
}, {escape: false});
[/code]
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:
[code language=”javascript”]
// 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});
[/code]
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...
Nice post. I was actually contemplating moving some actionFunction stuff to JS remoting and this nugget of knowledge will totally help.
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.
Your DE org is your packaging org?
Yes, my packaging org. Same in my patch orgs. My orgs are on NA7. Not sure if that makes any difference.
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.
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.
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 🙂
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 !
Great tip, thanks Wes. Lets just hope that a Salesforce “fix” doesn’t break this work-around. 🙂
This truly excellent Wes. Saved my bacon 😛
If there’s one meat worth saving it’s bacon! 🙂
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!
Salesforce is working on it. It should be ready by Spring ’14
Summer ’12 will help address porting VF remoting client-side invocation from DE orgs to installed orgs.
See http://developer.force.com/releases/release/Summer12/javascript+remoting+enhancement.