Detecting the sObject type of Id's from ambiguous fields

When dealing with the OwnerId field, it is important to check if it is a User or a Group sObject you are dealing with before you start using it or you'll get errors. The Task object also has a few ambiguous fields that match up multiple Objects like the WhoId and the WhatId. In triggers and in other logic you will sometimes need to detect what the object is to either exclude or include it in the next bit of code. We dont want to iterate through code and update records if we don't need to, it will bog down the system. 


I have seen some of the ways out there that are used, particularly the one where you check if the first 3 letters of the ID is '500' or '300' but i do not think this is an accurate way of detection. I want one that the system tells me for sure what object it is. Unfortunately its not as dynamic as i would like it to be due to limitations in APEX, but it is still a much better detection than the above. 


I first made a helper class called GlobalHelper_IsSobjectType and populated it with a few methods that look like the following. It takes in the Id and after a check to make sure that an Id was actually passed and is not null, it try's to create an Object of that Type. If it can it will not fall into the Catch and will return true, other wise it will error and return false, but it will not error in a way that will halt your program from finishing(thus why its in a try catch). 

I made one for Account, Contact, Lead, User, and Opportunity since those are the ones I typically have to detect. When it comes to the OwnerId field I can just use the one for User since if it returns false i know its a group. I also found that I needed to Overload the method so it would work with string as well as Id: 

Ideally I was hoping to make the above but make it more dynamic so you pass the object type you wanted to detect as well as the id for the detecting. That way you would only need one method instead of one for each Object, but I have yet to find a way to make it work. Now of course you need to test the code, and I prefer as close to 100% coverage as possible so:

Questions?  

Twitter: @SalesForceGirl  or Facebook

APEX Trigger to Prevent Duplicate Object Records

One of the biggest issues in Org's that I have seen is with duplicate records. But what is the best way to prevent this? With an easy trigger of course! 


Let take the Contact object, in my Org, everything is keyed off email, so we shouldn't have more than one contact with the same email address. And we need to not only protect against new Contacts, but we also need to ensure that if a User updates the email on the Contact that it too is not already in use before the update occurs. In order for the User to know that they are trying to Insert or Update incorrectly we will have a field error show next to the email of the contact stating that one already exists.


Lets make(or update) a Contact trigger for before insert and before update. 

We are going to use a Map to store the id and email of each contact that comes into the trigger so we can use that to do a SOQL query later when its time to see if it already exists.  add the 'trigger.isBefore' even though we know this will only occur before, so that this can be easily extended in the future and we wont have to go back and change code.

Now we need to populate the map with the Contact info so we can use it in the SOQL query next. We should also send up an error if the batch of Contacts that is being iterated over in the trigger contains more than one of the same email. 

Now that we have the Map populated, or at least in theory it should be, we will query the DB to see if a Contact already exists with that email, and if so, show an error to the User, other wise do nothing and allow it to be inserted/updated. 

And thats it. You can of course make this much more robust, so it not only compares email but also name and phone number too. 


Questions?  

Twitter: @SalesForceGirl  or Facebook

Visual force 101 - Style tips

Custom style in visualforce pages can be tricky if you don't have much experience with it. Sure the same rules apply with any HTML page, but there are a few tips that might help move things along. When trying to do custom style, the first thing to know is in the apex:page tag.

<apex:page standardStylesheets="false" ... >

This is designed to disable the style from salesforce from showing on their standard tags like apex:blocktable etc. This allows you to customize them to your liking without having to fight their style, and allows you to use salesforce's native functionality; no need to reinvent the wheel when you don't have too.

However this does not prevent their CSS from overriding yours. Which brings me to the next rule, use long/custom class names on your tags.

 <div class="AlertsMessageBox floatL">

If you use classes like 'btn' or 'button' for example, it would force salesforce's style on whatever has that class to look like their buttons. Which can be useful when wanting to mimic their buttons, but on non button or link tags like div's or span's the style seems to be missing padding, and I have yet to find a way to force it. So instead I use the thin button as a 'disabled' button, and when 'enabled' it appears to 'grow' into the real button.

When adding style sheets and js to the page it's best to use standard HTML input and script tags.

<script type="text/javascript" language="javascript" src="{!URLFOR($Resource.SelfServiceTemplate, '/js/jquery-min.js')}" ></script>

I have noticed that when using the apex:inputs the order the render as on page load isn't always consistent with the order on the page. Now this hasn't happened in their newest releases but i still try to use the HTML one just in case. Also make sure all CSS includes are above any js on the page, it has been found that if the are mixed or the js is on the top that it will sometimes cause errors with the js and brake the page. I have never seen it, but it's a good 'best practice' standard to keep.

In certain cases you'll need to force style, and two of the best ways to do that is with the !important hack and in-line style. Both of witch is a LAST RESORT, but are still acceptable practices. 

ul li{list-style:none !important; padding:0; margin:0;}

The !important hack is used to put emphasis on the attribute it is in, making it more 'important' than anything else that may try to override it. 

<div style="font-size:11px;">

In-line style works better in that way, but is more founded upon in my eyes due to it's obvious disadvantages. While making the code look messy, it also makes it harder to manage the style in any way since its not in a stylesheet where it belongs. BUT in-line style is the the 'last line of defense' in the cascade of CSS, since it overrides all. 

Questions? 

Twitter: @SalesForceGirl  or Facebook