The Silver Lining

Lessons & Learnings from a salesforce certified technical architect.

Salesforce: JavaScript Remoting and Managed Packages

with 16 comments

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) {
}, {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) {
}, {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...


Written by Wes

February 26, 2012 at 7:32 pm

Posted in SalesForce

16 Responses

Subscribe to comments with RSS.

  1. Nice post. I was actually contemplating moving some actionFunction stuff to JS remoting and this nugget of knowledge will totally help.


    February 26, 2012 at 7:52 pm

  2. 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?


      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.


      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 🙂


      February 27, 2012 at 5:23 pm

  3. 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

  4. Great tip, thanks Wes. Lets just hope that a Salesforce “fix” doesn’t break this work-around. 🙂


    February 28, 2012 at 10:22 pm

  5. 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! 🙂


      March 1, 2012 at 8:51 pm

  6. 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!


    April 22, 2012 at 11:20 am

  7. Salesforce is working on it. It should be ready by Spring ’14


    May 4, 2012 at 2:02 pm

  8. Summer ’12 will help address porting VF remoting client-side invocation from DE orgs to installed orgs.


    May 21, 2012 at 7:06 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: