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

The Mass Delete Controller

I will definitely take my time to explain this part as it’s the engine behind how this will work.  So let’s look at this in steps.

The purpose of this class will be to handle the mass delete of custom objects in a generic manner.  To do this we need the all the entities we created in Part II of this series.  So first we set those up in our class called the MassDeleteCustomEntityController which extends an IPagingEventHandler

Coming from a Silverlight Development background, they’re certain tricks I like to pull off.  So naturally, I configure my controller for this early.  I need a generic way to set and retrieve the state the view or certain elements of it are in, as well as context keys.  I call these the ViewModelState and ViewModelContext respectively.


Now we add the remaining properties to match the types from Part II along with some helpers such as SampleQuery which comes in handy for debugging and the MassDeleteSearherType through whom combined with some reflection allows us to instantiate the correct IMassDeleteSearcher from a given QueryString parameter.  This is where we get to the fun part of connecting the gears:

In our constructor, we must now remember to create our complex types as well as initialize them to their default values. For this example, I’m going to configure my custom search for 5 possible query combinations, but since we’ve written the classes so flexible, I could’ve just as easily retrieved this value from a query param. Also seen here, I default my paging record limit per page to 20 and i set the RecordCountLimit to 2000 to avoid going over governor limits in Salesforce.

My view model state of my CONFIRM_DELETE is defaulted to false as a way of telling my view to not render the confirmation section as yet.

Take note of how I used the little Reflection that’s available in APEX to my advantage.  I took the parameter from the query string for the custom type to use for my MassDeleteSearcher and I made an attempt to instantiate it.

 SOQL Generation

My SOQL Generation is actually quite simple given that we’ve built most of our helper classes.  This method I’m about to explain could’ve been placed anywhere and was not necessarily confined to this controller.  Quite frankly, I could’ve put it in a SOQL utils static class BUT  – I didn’t. 😐

First of all, we need a way to build a comparison line given an initial “WHERE String” (just incase one is prexisting and this needs to be appended to it – you’ll see…) and the Criteria to add.  I think I’m going to name her BuildCompareLine (yes, my methods are female.  Is there a problem?).  I should mention that this method cater’s for comma separation in the target values and takes that to imply the need for OR statements:

Now we got the main part for the generation.  Now we can aggregate it’s use to build a WHERE statement given a list of TCriteria:

To implement the search which will trigger the WHERE generation, we need to iterate through the Non-empty Comparison and FieldCompares in the DataContext(TCustomSearch) that were selected.  For each one that we find that qualifies(i.e. the user selected something), we create a criteria out of it and add it to a list.

With this information, we build the where statement.  From here, we acquire a count of total records for use in the paging.  However, we want to limit the count so as not to pass governer limits in the number of records being counted. Thus the reason for :

In addition, we must also cater for a default handler given that a MassDeleteSearcher was not instantiated.  So I pretty much prepared a basic Id display.  Altogether, it looks something like this:

 Record Deletion

Record deletion, is pretty straight forward.  If the user chose to delete the max batch size, delete all of them that met the criteria within the governor limit.  If the user chose to only delete the selected, do just that:

Sigh…lastly, we will need two methods for toggling the confirm portion for the deletion…unless you don’t plan on doing a confirmation. Your choice :s, and I won’t judge you for it:

And there you have it folks – The guts of the app.  The controller.  Now all we have left to do is the glory…The User Interface is coming up next in Tales of the Salesforce Spirit: Custom Object Mass Deleter (Part IV of IV).

Unless I realized that I miscounted the parts and it’s actually 5…or even 6.


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

Leave a Reply

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