Chapter 11 APIs and Extensibility


This chapter will discuss what tools might be at your disposal when the out-of-the-box functionality of the CMS runs short.

  • What is an event model?

  • How does repository abstraction allow the integration of other content?

  • In what ways might we want to customize a WYSIWYG interface for our editors?

  • How and why would we run batch jobs on content?

  • How can heavy use of plug-ins make my implementation hard to manage over the long-term?


On how the API and extensibility model causes the vendor's past development team to heavily influence your own current development team.

In a strange way, developers build a kind of time-shifted relationship with the original vendor team through the API. A clean, consistent, well-documented API gives a good impression of the vendor's team. The implementing developers learn to trust them, and build confidence that requested customizations can actually be achieved. When a user asks if something can be done, the answer becomes, “I'm pretty sure there's a way.”

A poor API is the exact opposite. Inconsistent and awkward APIs breed distrust among developers. In some cases, it seems like the API – and, by proxy, the vendor itself – is actually working against them. It's like having a team member who doesn't pull their weight and drags the rest of the team down. Whenever a customization is asked for, the answer becomes “I'll check, but I doubt it.”