Database customization and coding, it's all connected. |
- Data Types: When you create custom fields, you have to specify a data type: Date, Text, Currency, Number, etc.
- Polymorphism: When you use "+" in a formula for two text fields, it concatenates, when you use it in a formula with two number fields it adds them. This different behavior in different scenarios is polymorphism at work.
- Variables: Fields that let users input values are variables. They can be changed if needed, just look for the label you gave and edit the data.
- Constants: Your org ID is a great example of a constant. It's a value that will not change in your org.
- Objects: Okay, this is confusing. When you start programming, you will see that Salesforce objects are now referred to as SObjects. This is because object oriented programming languages use the term Objects to represent data collections. Oh, hey, that's what objects are in Salesforce too, basically. Only oop objects can also have actions related to them, things that you can do to them or things that they can do to other objects. Oh, hey, sObjects are the same if you think about workflows as actions that are related to specific objects and think of triggers as actions that let one sObject act on another sObject. So maybe this isn't confusing at all.
- Array: In the Salesforce database, you have a record ID associated with a bunch of fields -- record name, created date, etc. This is essentially an array of data. Apex uses the term List rather than Array, but they are the same. Lists can be multidimensional too. For example, you can have a list of data from fields for a single contact record, or you can have multiple records in a list and each of those records will have its own list of field values. List Views are two dimensional lists of data.
- Cast: In programming, you can force a variable of a particular data type to be treated like a different data type. Similarly, in Salesforce, you can use Formulas like Text(PicklistSelection__c) to force a field, in this case a pick list, to be treated like a different type of data, in this case Text.
- Model-View-Controller: This is easy for you. Model is the data model. When you create custom objects and fields in Salesforce, you are changing the data model, native objects and fields are also part of the data model. View is the user interface. When you edit page layouts, you are changing the view. Controller is any automation. You might add workflow rules or formulas to affect data based on rules and reasons you define.
- Boolean data: Think of a checkboxes. They are true or false, checked or unchecked.
- Boolean Operators: And, Or. You may be using these in formulas or in list view filters already. If you look for this value AND that value, both must be true. If you look for this value OR that value, only one of them needs to be true, but both true will work as well.
- SOQL: SObject Query Language lets you express in a few words the kinds of information you already use defining List Views. For a List View, you sepcify filter criteria for selecting specified fields from the given object. You might select First and Last Name from Contact with filters looking for records where the phone number is blank, for example. SOQL lets you express the same sort of thing when programming in Apex, using a few key words.
If you want to write code for Salesforce, Visualforce will handle the View portion, Apex will handle the Controller portion, and Salesforce will continue to handle the Model portion of your program. You will probably find yourself using data types you are very familiar with from Salesforce fields as you set up variables and constants. And you will find SOQL easier to understand if you think of them in the context of list views, returning lists or arrays of data you request.
For a more complete introduction to programming for the administrator, please watch this Dreamforce session on coding for non-developers: http://dreamforce.vidyard.com/watch/haqgdyryAtDoQdMsOieTTA