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
|
1 2 3 |
public with sharing class MassDeleteCustomEntityController implements 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.
|
1 2 3 4 5 6 7 8 |
//The map of string to bool to represent a twofold value //of the state of some attribute of the view model public Map<String,Boolean> ViewModelState {get;set;} //The map of string to string to represent an arbitrary //string of an attribute of the view model. It prevents //the creation of a plethora of properties on the controller //outside of its designated DataContext public Map<String,String> ViewModelContext {get;set;} |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
//Used for debugging information public string SampleQuery {get;set;} //The main data context for this controller that handles the search configuration public TCustomSearch DataContext {get;set;} //The list of records returned from a search public List<TSearchResultItem> SearchRecords {get;set;} //The class name of the type that implements what exactly is retrieved from the search public String MassDeleteSearcherType {get;set;} //The option to delete all records found regardless of what is selected on the screen public Boolean DeleteAllRecordsFound {get;set;} //The object responsible for paging the search results public TPaging Paging {get;set;} //The interface to the class that implements the custom search public IMassDeleteSearcher MassDeleteSearcher {get;set;} |
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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
/* @Summary: Default constructor for class */ public MassDeleteCustomEntityController (){ ViewModelState = new Map<String,Boolean>(); ViewModelContext = new Map<String,String>(); SearchRecords = new List<TSearchResultItem>(); DataContext = new TCustomSearch(5,ApexPages.CurrentPage().getParameters().get('et')); Paging = new TPaging(0,20,0); Paging.PagingEventHandler = this; Paging.RecordCountLimit = 2000; ViewModelState.put('CONFIRM_DELETE',false); DataContext.Initialize(); //main initialization happens now MassDeleteSearcherType = ApexPages.CurrentPage().getParameters().get('mdt'); if (TStringUtils.IsNullOrEmpty(MassDeleteSearcherType)) return; Type t = Type.forName(MassDeleteSearcherType); if (t==null) return; //create the instance of the mass deleter MassDeleteSearcher = (IMassDeleteSearcher)t.newInstance(); } |
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.
|
1 2 3 4 5 6 7 8 |
MassDeleteSearcherType = ApexPages.CurrentPage().getParameters().get('mdt'); if (TStringUtils.IsNullOrEmpty(MassDeleteSearcherType)) return; Type t = Type.forName(MassDeleteSearcherType); if (t==null) return; //create the instance of the mass deleter MassDeleteSearcher = (IMassDeleteSearcher)t.newInstance(); |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
/* @Summary: Method builds the comparison part of the SOQL WHERE statement */ public string BuildCompareLine(String pInitialWhereStatement, MassDeleteCustomEntityController.TCriteria objCriteria){ String result = ''; //cater for OR statements List<String> objSearchValues = objCriteria.TargetValue.split(','); String logical_compare = ''; String current_compare = ''; //get the field info DescribeFieldResult selectedField = DataContext.FieldInfo.get(objCriteria.FieldName).getDescribe(); for(String sValue: objSearchValues){ current_compare = objCriteria.FieldName+' '+DataContext.ApplyTemplate(objCriteria.Comparator,sValue,selectedField.getType()); logical_compare = logical_compare + (!TStringUtils.IsNullOrEmpty(logical_compare)? ' OR '+current_compare : current_compare); } result = !TStringUtils.IsNullOrEmpty(objCriteria.TargetValue)? (!TStringUtils.IsNullOrEmpty(pInitialWhereStatement)? ' AND ('+logical_compare+')' : '('+logical_compare+')' ): ''; return result; } |
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:
|
1 2 3 4 5 6 7 8 9 10 |
/* @Summary: Method iterates through the fields and builds the where statement */ public string BuildWhereStatement(List<MassDeleteCustomEntityController.TCriteria> pFieldCompares){ String result = ''; for(Integer i=0; i<pFieldCompares.size(); i++){ result += BuildCompareLine(result,pFieldCompares[i]); } return result; } |
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 :
|
1 |
string sQuery = 'SELECT COUNT() FROM '+DataContext.EntityType+' '+ (!TStringUtils.IsNullOrEmpty(WHERE_QUERY)? ' WHERE '+ WHERE_QUERY + 'LIMIT '+string.valueOf(Paging.RecordCountLimit) : ''); |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
/* @Summary: Method executes the search by gathering the field criterias, building the SOQL WHERE statement from them, then passing it to the MassDeleteSearcher to decide what fields to select based on the Entity Type */ public void Search(){ String pTemplate = ''; String pValue = ''; String WHERE_QUERY =''; List<MassDeleteCustomEntityController.TCriteria> objFieldCriterias = new List<MassDeleteCustomEntityController.TCriteria>(); try { for (Integer i=0; i<DataContext.ComparisonOptions.size(); i++){ if (TStringUtils.IsNullOrEmpty(DataContext.ComparisonOptions[i].SelectedOption) || TStringUtils.IsNullOrEmpty(DataContext.FieldOptions[i].SelectedOption)){ continue; } objFieldCriterias.add(new MassDeleteCustomEntityController.TCriteria(DataContext.FieldOptions[i].SelectedOption, DataContext.ComparisonOptions[i].SelectedOption,DataContext.TargetValues[i].DBConst)); } if (objFieldCriterias.size()==0){ return; } WHERE_QUERY = WHERE_QUERY + BuildWhereStatement(objFieldCriterias); SearchRecords.clear(); //get the overall size string sQuery = 'SELECT COUNT() FROM '+DataContext.EntityType+' '+ (!TStringUtils.IsNullOrEmpty(WHERE_QUERY)? ' WHERE '+ WHERE_QUERY + ' LIMIT '+string.valueOf(Paging.RecordCountLimit) : ''); SampleQuery = sQuery; Paging.TotalRecords = Database.countQuery(sQuery); //configure buttons on inital load if (Paging.Offset==0){ Paging.EnableTrigger = false; Paging.First(); Paging.EnableTrigger = true; } if (MassDeleteSearcher !=null){ SampleQuery = WHERE_QUERY; SearchRecords = MassDeleteSearcher.GetSearchRecords(WHERE_QUERY,Paging.PageSize,Paging.Offset); } else { //default display for undefined implementations SampleQuery = String.format('SELECT Id,Name,CreatedBy.Name, CreatedDate FROM {0} {1} LIMIT '+Paging.PageSize+' offset '+Paging.Offset,new string[] { DataContext.EntityType, (!TStringUtils.IsNullOrEmpty(WHERE_QUERY)? ' WHERE '+ WHERE_QUERY : '') }); List<sObject> pSearchRecords = Database.query(SampleQuery); for(sObject sr: pSearchRecords){ TSearchResultItem pSRI = new TSearchResultItem(sr.Id, (String)sr.get('Id'),DataContext.EntityName,DataContext.EntityType,sr); SearchRecords.add(pSRI); } } } catch(Exception e){ //you should add a page message here } finally{ ViewModelState.put('CONFIRM_DELETE',false); } } |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
/* @Summary: Executes the delete based on the options selected in the interface */ public void DeleteRecords(){ List<sObject> objValues = new List<sObject>(); if (DeleteAllRecordsFound){ Integer pOriginalPageSize = Paging.PageSize; Paging.PageSize = 200; Search(); Integer upperBound = SearchRecords.size()>200? 200: SearchRecords.size(); for(Integer i=0; i<upperBound; i++){ objValues.add(SearchRecords[i].DataContext); } Paging.PageSize = pOriginalPageSize; } else{ for(Integer i=0; i<SearchRecords.size(); i++){ if (SearchRecords[i].Selected && objValues.size()<200){ objValues.add(SearchRecords[i].DataContext); } } } try{ delete objValues; Paging.First(); //you should add a page message here }catch(DmlException e){ //you should add a page message here } catch(LimitException e){ //you should add a page message here } catch(Exception e){ //you should add a page message here } } |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
/* @Summary: Method shows the confirm delete by toggling the ViewModelState settings */ public void ShowDeleteConfirm(){ ViewModelState.put('CONFIRM_DELETE',true); } /* @Summary: Method hides the confirm delete by toggling the ViewModelState settings */ public void HideDeleteConfirm(){ ViewModelState.put('CONFIRM_DELETE',false); } |
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.