Writing Components For CiviCRM

For the last six months, I've been working on a system called CiviVoter, which is a component of CiviCRM that manages a voter file (the kind you get from your local registrar of voters here in the US) and imports it into CiviCRM. Besides doing the obvious -- manage voter records as contacts -- the component implements an API for doing what political campaigns world-wide do with a voter list: dividing it up between their volunteers, and calling the voters on the phone ("phone banking") or meeting the voters face-to-face by going door to door ("foot canvassing", "door knocking" or just plain "canvassing"). I've written about the application side of this on the developer's list, and on my demo site for CiviVoter. But here I'd like to write a bit about what exactly Lobo and folks mean when they call software like CiviEvent or CiviMail a "CiviCRM component", and what it takes in the 1.x versions to write a component. So how do you write a component for CiviCRM? It's not a simple task, and I won't be able to do this in one post. But here's a bit about what a typical component in CiviCRM does: * The component defines a set of data base tables, and how the data base library CiviCRM uses should access that data and manipulate it. The data typically represents data objects that are "attached" to a contact (events, memberships, and so on), or it can "extend" the contact type (the Quest system, and CiviVoter). *The component sets up the UI to edit and view its data. *The component fits into CiviCRM's query generator to handle searching for its data, and to allow contacts to be searched by criteria relating to the component's data. Note this is different that writing "an extension" to CiviCRM. Typically, an extension is a module (nearly always a Drupal module) that uses a number CiviCRM hooks to modify how a contact is created or saved, or to add bits of UI like links to the CiviCRM UI. You can find good examples and docs for this on the CiviCRM wiki, and I'm going to direct you there. Instead, a component requires adding classes to the core CiviCRM class files, and in many cases, modifying a few key classes in Core to get your component initialized and loaded when needed. Extensions are pretty easy, and you don't need a lot of experience to write one. But components assume that you are comfortable with object oriented PHP code, and that you are good at finding your way through a large library of someone else's code. You should be a fairly experienced software developer before you take one on. I'd like to tell you that writing a component uses a simple API. It isn't, and it wasn't: getting CiviVoter to work has been a trial and error project, since many of what I'll call "integration points" are not documented. But it is possible, and you can profit from my experience with it, I think. In the next few posts, I'll go over portions of the process, and last, I'll give some suggestions of changes that could be made for CiviCRM 2.0 that would make the process easier, and increase the number of people and projects that can be done as components.

Comments

Rob:

Great post :) thanx for taking the time to start writing your experiences with CiviVoter and the component model. we'd love to hear your feedback and changes we can/should make with regard to this in 2.0

One of our goals in 2.0 is to make components independent of core (i.e. like drupal modules). You need not hack core to add a component. The other goal is to define and document the interfaces. Finally we'd like to "component-ize" CiviCRM and make the system more granular