The aim of this session is to introduce a framework and methodology to guide module developers through the plethora of choices of APIs (both core and contrib) and architecture approaches that they can use to build their Drupal modules.

Here is the scenario:

You are building your brand new Drupal site and are happily configuring modules and finding solutions amongst the hundreds of Drupal modules out there until you eventually come across a requirement that is not met by a core or contrib module.

At that point, brave Drupal developer, you need to build your own custom module or, even better, a module that you can contribute back to the community.

Where do you start?

Drupal core offers a nice set of APIs that seem to cover a lot. But then there is also CTools. How about the Entity API? And do you want to integrate with Rules? If you are doing lists you may want to build some Views? Are you going to incorporate libraries - have you heard of the Library API?

The session is going to propose a set of guidelines that can help with choices and can quickly point new developers in the right direction. We will also explore the architecture of some of the more popular modules that tie together several APIs to extract some best practices from those approaches.

The context and background to this is my own experience in building custom modules and a larger contrib module (http://drupal/org/project/rooms) that ties together different APIs and approaches.