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!

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;
    }

Spot the difference.

Many people are finding that their tests are reporting different degrees of test-coverage in different environments. There are a few things to check if you are getting inconsistent results but there’s a new bug in the wild. Before you assume you have the bug make sure that you’ve:

1. ‘Run All Tests’ in each environment. This will tell you a few things viz.
• Perhaps there are tests failing that are bringing coverage in that environment down.
• There are some tests that only fail when run in the browser e.g. MIXED_DML_EXCEPTION will not rear it’s head through the IDE.
2. Click the ‘Compile all classes’ link above the Setup > Develop > Apex Classes view. I’m not sure when this lil’ bugger first appeared but it’s darn useful. Essentially it makes sure that all the dependencies in your code are fulfilled e.g. if page A uses controller B that in turn refers to utility class C it’ll make sure each of those pieces exist and work (as far as compilation goes at least).
3. Double-check your test classes to make sure they’re not data dependent. If they are and you have different types/amounts of data in your respective environments it’s 100% feasible that the test coverage will be different.

Now if you’ve checked all of the above you might have been afflicted by a new bug which, for some reason, counts braces, whitespace (and more!) as being uncovered by your tests. This is preposterous of course and to fix it simply remove all test history from the deranged environment. Re-running the test and/or deploying them should now be back to normal!

I’ve had to do this a few times but infrequently enough for me to forget how to do it each time. Forgetting things isn’t usually an issue because of our Google Overlords and their mighty The Google but it’s quite a journey down the rabbit hole to find this specific information.

The reasons it’s tricky to find is because the setting that controls whether an email is sent to the user on creation is not directly associated with users but with DML. Long story short you need to set a particular Database.DMLOption e.g.

User u = new User();
// Add some details here ...

// Set the DML options
Database.DMLOptions dlo = new Database.DMLOptions();
dlo.EmailHeader.triggerUserEmail = false;

Database.insert(u,dlo);

Hopefully this information will now be easier to find next time I forget

Shannon is Senior Product Manager for Declarative Apps at Salesforce.com

@abhinavguptas and I were curious as to the identity of the creator of the SetupScripter, which is now incorporated into the salesforce.com Org setup menu. I dug around a bit and managed to uncover her real identity – community please meet Shannon Hale, Shannon Hale this is the community. She didn’t just stop with that wonderful piece of UX but has moved onto bigger and better things, but I’ll let her tell you about those.

If you’d like to learn more about the genius that is Shannon or just have a chat with her you can get her on twitter at @shannonsans or @bathtubdreamer. You can also check out her online presence at shannonsansserif.com and bathtubdreamer.com.

Onto the Q&A!

I started out as a writer, but in a different field — I wrote and edited for some independent Canadian music and culture magazines. I started technical writing to help pay the bills, and from there wandered through a series of tech positions: technical training, systems analysis and design, and software development. In 2001 I became obsessed with why a product I was coding was difficult to use, and began to independently study interaction design and user experience.

When I’m not being a complete geek — which I am even at home, I always have personal and volunteer web projects going on — I’m sewing, knitting, or binding books. I’m one of those people who always needs to be doing something with their hands.

Yip it’s that time again and boy do we have some very cool speakers this time around. The gig is at Skillsmatter at 6.30pm on 20 October and is summarised in the info below. Please don’t forget to RSVP. Of course there will the be usual beers and pizza

Hope to see you there!

AMJAD KHAN ON FORCE.COM ERD USING SCHEMASPY

Amjad Khan will give a talk to the SafesForce user group on How to Install and run SchemaSpy on any Salesforce Org to generate an ER diagram. More details…

SIMON GOODYEAR ON MAKING BETTER USE OF INTERFACES ON THE FORCE.COM PLATFORM

Simon Goodyear’s talk for the SalesForce user group will give a quick overview on what interfaces are, how you can make better use of them in APEX, and what we gain from doing so. More details…

TESTING ON THE FORCE.COM PLATFORM

Keir Bowden gives a talk for the SalesForce User Group on Testing on the force.com platform, covering TDD, unit testing, continuous integration and test scripting. More details…

EFFECTIVE B2C MANAGEMENT

Stony Grunow gives a talk for the SalesForce User Group on Effective B2C management for companies using the “Contacts and Organisations” package. More details…

TURNING YOUR ORG INTO A FULLY OPERATIONAL BATTLE STATION USING RUBY AND SELENIUM

Bruce Durling will give a talk for the SalesForce User Group on turning your org into a fully operational battle Station using ruby and selenium More details…

You Shall Not Pass!

There are a number of ways to authenticate with the Force.com Platform and I thought I’d create a few lightning posts documenting my findings for each.

The first method in this series will be logging in through the web interface. There are 2 sites that you would hit in order to authenticate:

1. http://login.salesforce.com – for Developer Edition and Production Orgs
2. http://test.salesforce.com – for all other sandboxes

If you’re not able to log in with a username and password that you know is correct then the first port of call is to check that you’re using the correct URL above. I’ve seen many developers forget to hit ‘enter’ after swapping “test” for “login” (or vice versa) and then being puzzled because their credentials still didn’t work so don’t forget (okay by “many developers” I actually mean me).

There’s also a neat trick that’s quite well-known and can be used to log you in automatically based on bookmarked URLs. All you need to do is append 2 URL parameters onto the appropriate environment HTTPS URL e.g. I could create a bookmark with the URL https://test.salesforce.com?un=wes@cloud-corporation.com&pw=abc123 where:

• un = your username for that environment
• pw = your password for that username

Pro-tip: Make sure that the URL is using HTTPS.

If you exclusively use Chrome you might want to use the Force.com Logins plug-in which will save you some hassle.

Irregular Expressions

I get very sad when discussing this particular topic. There are a variety of ways of get Visualforce component Ids and using them in JavaScript but all of them keep me awake at night. Srsly. A commenter on one of my posts got me thinking about how we can do this better and I’ve come up with a way that I think is great. Hopefully you’ll agree.

This post means that my older posts here and here are now retired in favour of this method.

If the world was on the brink of nuclear war with no clear path to peace what could you count on to save the day? Regular Expressions of course. If a meteor the size of Pluto was about to crash into Earth and Bruce Willis was too old to land on it and blow it up what could we count on to rid us of the troublesome rock. Yes that’s right, Regular Expressions. I think you can guess where I’m going with this.

jQuery has the ability to understand very simple regular expressions in it’s attribute selectors. The full documentation can be found here.

To solve our particular problem however the code is simple:

<apex:page>
    <head>
        <style>
            a,span{
                display:block;
            }
        </style>

        <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

        <script>
           jQuery(document).ready(function($){
               $('#btn').click(function(e){
                   e.preventDefault();

                   console.log('The following element was found when looking for an id of \'output1\':');
                   console.log($('[id$=output1]')); /* Here's where we're grabbing the element. */
               });
           });
        </script>

    </head>

  <apex:outputText value="She sells seashells by the seashore." id="output1"/>
  <apex:outputText value="Peter Piper picked a pack of pickled peppers." id="output2"/>

  <a href="" id="btn">Click me.</a>

</apex:page>

The important part here is the selector $(‘[id$=output1]‘) which says, “Find the id value that ends with ‘output1′”. This comes with a warning though! Do not duplicate the Visualforce Id that you give to your elements otherwise this piece of code will find all of them.

When I first wrote this post I used a selector extension library that gives you the full power of JavaScript-based regular expression but Ryan Fritts has rightly shown that the above will deal with 99% of use cases and is simpler. For those of you that need to deal with the extra 1% I’ve implemented a wrapper to regex selector as an example. It does exactly what jQuery is doing above and gives you access to the regex flags as documented here.

Thanks again Ryan!

I’ve worked with many Org instances in my career with salesforce.com and the Force.com Platform and was stunned by an Org that had a massive number of Roles, way beyond anything I’d ever seen before. This made me curious as to what other people were dealing with and I’m sure the result will be interesting.

Note: If you work with several Orgs and you have a high tolerance for boredom please submit an answer for each

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!