Archive for February 2012
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...
Salesforce: JavaScript Remoting – a different way of thinking
Remoting is awesome.
JavaScript Remoting for Apex operates in a very different paradigm from what you might be used to i.e. Visualforce pages have controllers and the two interact through action methods – where this might be a full form submission or some neat AJAX functionality. Remoting also calls controller methods but there is a gaping maw in terms of how the two work under the hood.
I’ve seen a few great articles on the syntax and example usage of JavaScript Remoting for Apex but when I started using it I came across a number domain differences that weren’t documented anywhere. Hopefully my list here will help you in the learning process. The best way to describe the new way of thinking is to examine the features set in contrast to “normal” Apex and Visualforce.
How JavaScript Remoting Differs
- Pass parameters naturally i.e. the call matches the method signature syntactically instead of requiring <apex:param/>.
- Action methods when called in “normal” Visualforce can only return NULL or a PageReference. Remoting allows you to return a wider range of data types, even objects and collections.
- Remoting methods have no access to the view state e.g. if a static variable is initialised to some value (outside the remoting method) a remoting method will see this as NULL unless it is re-initialised in that method! Conversely if a remoting method sets a state variable value the scope of that value is only within that method.
- It’s much faster. I’m building an application at the moment that is 95% backed by JS Remoting and when I show it to other developers they are struck dumb for at least 3 hours because of the speed.
- Neater debugging info in the browser console. Salesforce has done a great job of providing feedback directly to the browser’s console log.
- Each method call gets its own executional/transactional context i.e. fresh governor limits per call!
If I’ve missed anything please let me know and I’ll add it. Viva la knowledge crowdsourcing!
Salesforce: Dynamically determining the field type of a dynamically determined sObject
This solution is quite difficult to find.
Call me crazy but I need to do this from time to time, and every time I do I can’t remember how I did it before! So I then trudge through the API and the Apex docs until I find the answer and that’s no mean feat in this specific case. Well, no more my friends because I’m putting it right here on this very blog!
In short the code below will return (as a String) the type of field that we’re working with. Neither the name of the object or the name of the field need to be known in advance.
public static String getFieldType(String fieldName){
// Assume that "sObjectName" is populated elsewhere
Schema.SObjectType t = Schema.getGlobalDescribe().get(sObjectName);
Schema.DescribeSObjectResult r = t.getDescribe();
Schema.DescribeFieldResult f = r.fields.getMap().get(fieldName).getDescribe();
if (f.getType() == Schema.DisplayType.String){
return 'String';
} // .... else if
return null;
}
The Silver Lining 