E-mail
Different libraries for accesing SQL
Integration with Drupal is via _menu and _user (registration and my account, deleting a user)
We take over from CiviCRM_Invoke
CiviCRM is pear based.
- Quick Form
- Quick Form controller (for wizards, import mailing etc)
- BD_DataObject (precursor to active record. Think about data in terms of objects, rather than colums)
- Smarty (used to be pear)
Templating is smarty based
Jquery for Javascript
Directory structure
- top level is CRM for php
- templates for tpl
- packages for third party libararies (this is the reason why CiviCRM is pretty large - 2/3 of the stuff is PEAR JS, etc.
CiviCRM has two types of object:
- Page
- anything without a submit action eg CRM_Core_Page
- Form
- anything with a submit button eg CRM_Core_Form
All screens inherit from these two objects.
General order of processing:
- url -> figure out page to display -> instantiate the page -> execute the page
- execute the page: gets from the db -> process -> expose to tpl -> render
- so you can expose objects to the template e.g. $event object is exposed so you can use $event.title
The schema is defined by an xml template
- gencode generates DAO and civicrm.mysql
- Then there is a set of files BAO
- Both DAOs and BAOs refer to tables
- So the BAO is where you try to keep consistency between tables. In partnership with innodb.
- so we use innodb and on delete cascade.
- we will also soon use triggers to do things like automatically update display name, sort name, etc, but can't do that at the moment because of MySQL permissioning at 5.0 triggers need super user
Forms are built in a couple of steps:
- Preprocess (before the form is rendered if you want to set anything up
- Build builds the form
- Validate validates the form
- PostProcess - once it is submitted,
- When you submit the form, Form build Validate, and if validate is good, postprocess
All civicrm hooks should start hook_civicrm_
So to extend the form without changing core, you can:
- use the hook Hookbuildform which maps to preprocess and buildform
- use hook_validate to validate
- use hook_postProcess for postprocess
- If you use hook_buildform you can use the pear helper functions
You can tell the hook to render the new form elements automatically at the top or bottom of each form.
The CiviCRM schema and big objects
Contact is the main object around which the whole system revolves.
Then there is the contribution object, participant object, membership object,
Custom data
When you create a custom group of custom data, you create a new table, and new fields are new columns
You can think of CiviCRM as having two types of table
- One which collects all data from the user, and
- another that has all configuration options. Eg: custom_group and custom_field
Whenever you read or write to a custom hook, you fire off a hook.
So this means you can make a hook that calculates a custom field that is generated based on other fields or in fact anything
as an aside it would be nice to do an interface that eliminates the need to do that.
We don't create a DAO that defines custom data that is stored in civicrm_cache
ACL
You can control a lot of high level permissions in Drupal.
You can also slice your contacts and say that different groups of users can see different types of contacts
If you have 3-10 ways that that you can do that using the UI
If you want to slice it in more complex ways you can slice and dice in different ways
There are a couple of generic tables: option_group and option_value. You can use these to store name_value pair arrays
Lets go through all the hooks
