Friday, October 21, 2011

Project HardBoil: Day 1

To make HardBoil work really, really well, in the ideal world, it would link to the Google spreadsheet for the data and then validate the spreadsheet and its contents against the developer's Salesforce org.

However, in the real world (and in the interest of actually using this code to meet an immediate need for my own, full-time employer), the ideal will take way too long with too much technical expertise that I just don't have at this time. Also, I don't want to waste time just yet with trying to figure out how to create a GUI that allows the user to login to Google and pick out the spreadsheet with the test data.

So, where does that leave me with a day of progress?

I've created code that begins to define the following classes:
  • HardBoiler
  • SObject
  • SObjectField
  • SObjectRecord

Forcing my way into my Google Account and hard-coding the authentication and spreadsheet selection, I was able to setup HardBoiler to be constructed with a parameter for the spreadsheet's Zend_Gdata_Spreadsheets_WorksheetFeed. This in theory allows HardBoiler to initialize with the right Salesforce records by iterating through each row in each worksheet.

Everything looked good until I got down to the field level for a specific record, where Google did something interesting that screwed up my original plans: Google treats my column header as the key in an array that represents a row of cells in the spreadsheet; but the key is the column-header in lower case with non-alphanumeric characters stripped out.

My original plan was to use the column header to hold the fields' API names, but now it looks like my immediate challenge will be to figure out a plan B for enabling the code to match cell values to fields.