Tales of the Salesforce Spirit: Custom Object Mass Deleter (Part II of IV)

To be honest with you, I really didn’t expect the explanation to be this in depth, but you never know until you start.  So here we cover the question “WHAT ARE THE BASIC CLASSES THAT WE WILL NEED FIRST?” I think we’ll need about 6 of them:

  • TCriteria
  • TPaging (With it’s Respective IPagingEventHandler interface)
  • ISOQLValueConverter
  • TSelectionEntity
  • TApexEntity
  • TCustomSearch

TCriteria

The purpose of this class is to handle the search criteria for the objects.  It consists of a field name (the object field to compare such as First_Name__c), a comparative element (such as ‘=’, ‘<‘, ‘!=’, etc.), and a target value (such as ‘bub’).  All together a criteria can produce a concatenation of <field name>+<comparator>+<target value> (such as First_Name__c = ‘john’).  Can you see where I’m going with this? My intention is to generate SOQL statements :).

 

 

TPaging

Now we know that as of the time of this writing, SalesForce limits us to a 200 record max limit on a SOQL/SOSL query.   As a result, we will need a reusable way to page these records. This is why I’ve created the TPaging class. The purpose of this class is to act as a paging model for data sets. The code snippet bellow thoroughly explains the properties of this model and the application of each.

 

 

 

ISOQLValueConverter

Yes I know, I stole the name from Silverlight’s IValueConverter in System.Windows.Data.  I’m a Silverlight Developer at heart ;).

    Now, after swimming in the sea of SOQL for a while you encounter a few uncomfortable “biters”.  One of the most provoking ones being date to string value conversion. You can only force a user to do so much on the UI after a while. I ran into a situation where I needed to convert the value the user entered for a date into the one and only form that was compatible with SOQL.  Yes, this can be done using the typical if statements and other basic programming constructs. But what happens when constraints are introduced indefinitely for more and more types? Do I increase my comparison statements? We must keep in mind that case statements are not available in APEX.  I figured the best solution must be one where both the run time and ease of implementation is considered.   With an interface like the ISOQLValueConverter,  I can create a registry of value converters indexed by their respective field types, therefore allowing me to access the appropriate conversion method in a runtime of O (1).

    Now the value converter requires two method implementations.  These are called ConvertForward (convert original value into new format) and ConvertBackward (convert SOQL value into a presentation/original format).  The later isn’t required for now, but it is good to have for unforeseen issues.

Since our focus isn’t value converter’s, I’ll show only the main one of interest – the DateTime value converter.  First off, because of the lack of true namespaces, I’m just going to create a class to house a few sublcasses.  This is my make shift namespace:
Going off of the documentation…and working code ;), I know that the datetime format in SOQL is YYYY-MM-DDThh:mm:ssZ . Using this knowledge, the conversion goes a little like this (keep in mind this is INSIDE of the SOQLValueConverters class we just made):
As a gift, I’ll also show the DateValueConverter  because I believe the DateTime and Date properties are the most frequently occuring ones that require conversion.
 

TSelectionEntity

I’ve often found myself in need for a very simple object – an entity that provides a list of elements to select from as well as the selected option.  Strangely enough, I could not find an existing model for that and so I made a very straight forward one as seen below.

 

TApexEntity

This is just a generic ancestor class I use to descend any custom classes that need to act as models from.  It only has a single property for storing a string value.  This will come in handy for the comparison values.

 

TCustomSearch

Now we need a way present a set of comparison and field options,  as well as collect their respective target values in context of the current entity type in question. That’s the purpose of the TCustomSearch class.  It uses lists of TSelectEntity to store the available comparison options, and field options for each criteria we choose to add.  In summary, I tell my custom search how many field criterias I’m allowing for a given entity type and it builds the options to configure each filed for me. Each method and it’s respective parameters are documented below.  Please take note of the method LoadValueConverters  and how it registers the value converters we previously made.

 

Yes, I know it seems like a lot, but it’s all in your head.  Mere figment of your imagination. Just wait it out…Next the core logic – Tales of the Salesforce Spirit: Custom Object Mass Deleter (Part III of IV)

titancronusTales of the Salesforce Spirit: Custom Object Mass Deleter (Part II of IV)

Leave a Reply

Your email address will not be published. Required fields are marked *