Posts Tagged ‘AJAX’
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: Debugging JavaScript
Alert(). Old skool and not in a good way
I love JavaScript, and working within the Force.com Platform I’m always finding new ways that it can be applied to business needs. I know this is the case for many developers out there but I’ve seen that their typical development process is:
- Develop the JS code
- Create bug
- Include calls to the alert() method to troubleshoot
- Iterate
alert() is bad for debugging
I’m sure this process sounds familiar to many of you, but do you know what, the alert() method is a very weak way of troubleshooting. I abandoned it years back because of poor features such as outputting object representations as ‘[object]’ or ‘[undefined]’ – which doesn’t give you a lot to go on.
Meet console.log()
Modern browsers have access to a library called ‘console‘ which offers a far richer experience, and without the annoying pop-ups. The console.log() method accepts any JavaScript type as a parameter and will always give you detailed and sensible output. In the images below I’ve passed the method a variable representing a Div and the log outputs the entire DOM from the Div down. You can even pass it jQuery objects and it’ll output all of that object’s associated data!
Console. Unobtrusive with richer output.
Now that's what I call a debugger!
So where does it output to? On the console tab of course. I almost always use Chrome these days and you’ll find the console tab if you open Chrome’s Developer Tools. It’s similarly placed within Firebug for Firefox.
For those who’d like to learn more about the console library here’s an excellent article. There you’ll see that the library has far more to offer than just the log() method.
Debugging Custom JavaScript Button
A neat tip to remember is that console.log() is available wherever JavaScript is used on the platform. That means you can even debug the JavaScript you use to access the AJAX API through Custom Buttons!
The Silver Lining 