This article is a follow up to "Drupal 7 Field API - A simple example". This article is intended for programmers. We build a proof-of-concept module who's sole purpose is to demonstrate features of the Drupal 7 Field API.

Please note! Folks should always start their learning process by reviewing the official "Examples for Developers" on Drupal.org. I also recommend that programmers peruse Drupal's source code itself to find real-world examples that follow best practices.

Links to the full source code listings are located at the bottom of this article.

Figure 1

Our new module is called "my date".  We add several new features: the ability to style the date display; better control over the default date values; use of the JQuery date picker widget to select dates.

In the screen shot (Figure 1) we see 2 different content types. I've configured a custom display for each of the 2 content types demonstrated in the Figure 1. "my date" allows you to customize the display through configuration dialogs detailed below.

I broke each of the date instances in to 4 HTML div elements: container, month, day, year.

In addition, each of the date parts (month, day, year) can be toggled on or off (displayed or not displayed). In the Figure 1 examples, I turned the display of the year off.

I also allow an HTML style attribute to be applied to each HTML element. Again, that is the container div, month, date, year.

The date can be aligned (float) either right or left.

You also have the option of choosing a back ground image.

I am not a graphics designer nor a themer.  The idea was to show you how easy it is to set the configuration controls  .

Drupal 7 allows you to create a separate configuration for a teaser view versus a full view, etc.

This article is for PHP programmers and those folks who are comfortable working directly with relational databases.

Stored procedures are not a general purpose solution. However, as Drupal is adopted by wider audiences, you may find your self in a situation where a dedicated solution is required (e.g. making calls to stored procedures).

For example, a customer wants Drupal to report the result of a tried and true scientific calculation. The calculation resides in a stored procedure. Drupal may be new to the customer, but the customer's core business processes are well established (i.e. the stored procedure is established).

This article provides a simple proof-of-concept example to get you started. This article does not represent a comprehensive study of Drupal 7 and stored procedures. To summarize, I found this to be an interesting topic.

Using a stored procedure, record selection was 14 times faster (versus a prepared statement via db_select).

Background:

The main advantage of stored procedures is performance.

The main disadvantage is, store procedures are usually vendor specific. Often a stored procedure written for one database (e.g. MySql) can not be run in another database (e.g. Postgres).

A database administrator (DBA) often writes the stored procedure. An application programmer writes code that calls the stored procedure.

The term stored procedure refers to "application logic" stored directly in the database (as opposed to application logic stored in PHP files). Application logic is thus run (and stored) within the database, reduces network traffic.

Case Study Details.

We are going to write 2 simple functions. We'll perform some crude timings and look at the results.

Both methods simply select "titles" from all nodes of a specific content type and publishing state. Not a real world query, but enough to demo performance difference. I am using MySql version 5.5.9 running under Arch Linux 2.6.37. I am using the current Drupal 7.0 release. The database server, web server and Drupal installation all resided on the same host (my laptop).

The first method uses the Drupal API method db_select(), the second method calls a stored procedure. Other than that, both methods are the same. Both methods take the database result, capture a timing value and display everything using theme_table().

Timing results (measured in seconds):

This post is part of a series. We discuss how to build a custom module using Drupal 7's API.

In our previous posts "Drupal 7 Multi-Step Form (FAPI) with Table Report" and  "Making Our Report Sortable and Paged - Drupal 7 Multi-Step Form (FAPI)", we created a multi-step form that allows users to add new records. We display a synchronized (dependent) table report which is both sortable and page-able.

In this post, we add  "Modify" and "Delete" record operations. The following screen-shots display our new form and report.

In order to accommodate the new record operations, we add a field set. The field set notifies the user which record operation is currently selected ("Add" is selected by default). The field set acts as a container for the record operation form. Our module dynamically changes the field set and form elements when users select a record operation (E.G. Add, Modify or Delete).

The following screen-shots display the new "Modify" and "Delete" form elements.

The "Modify" operation works the same way as the "Add" operation. Both operations are divided into 2 steps (AKA multi-step).

Our module now supports three record operations. Thus our module requires additional source code instructions. It's a good practice to keep your internal design (source code structure) modular. Keep the size of individual methods as small as possible. Well organized source code allows the developer to identify logic flow. Well organized code supports changeability. a measurement of how easy is your code to change.

In that spirit, we divide the form definition (hook_form implementation) into helper methods.

We just posted our new online tool which generates a full custom Drupal module. This post talks about that tool and how modules fit in to the Drupal ecosystem.

A little background first. Occasionally Jason and I will answer questions on the Drupal.org Module Development and Code Questions forum. Some time last year, someone asked for a "Hello World" module.  A "Hello World" application is a barebones implementation of any development environment. If you read any books that cover programming languages they inevitably start with a "Hello World" example. So on the Drupal.org forum, I posted a simple "Hello World" module for Drupal 7. That post generated an unusual amount of interest. Therefore we decided, rather than just repost the "Hello World" example, we would create a tool to allow folks to generate their own.

So our online tool allows you to name the module and customize the package name. The module itself, is still only going to do 2 things:

• Creates a menu item link (so folks can click and invoke the hello function).
• Creates a custom function which simply displays "Hello World"

However, for a developer, the tool

• Creates the proper directory structure and name.
• Creates the proper file listings.
• Creates a custom "info" file that allows you to install your custom module in your Drupal installation.
• The source code includes an implementation of hook_menu().

So the developer gets a starter it. You can add addition functions, menu items etc. The proper naming conventions are started for you (by our tool).

In this post we going to demo how simple it is to create dynamic forms with Drupal 7 Form API (aka FAPI).

Our form will have 2 select lists (aka drop down combo boxes). Our first list lets a user select a US State. Once a state has been selected, we dynamically render a "city" select list. The city select list only contain cities for the selected state.

We will include a submit button, however the form will be submitted asynchronously (aka via AJAX). 

Upon submission, we will asynchronously render a short message. The message tells the user which city they just submitted.

In this post we are going to use the custom field "news_date" described in the previous post "Drupal 7 Field API - A simple example".

The module in this post automatically installs a content type with two instances of our "news_date" field (begin and end). 

First a little background:

Drupal 7 introduces the  concept of "entities"  A "node" is a specialization of an "entity". Content types are a further specialization of "node".

An entity can be defined as "fieldable" (which node is).  Thus, "content types" are also "fieldable" (i.e. we can add fields).

The following example uses Drupal 7 beta 3 release. A simple introduction and demonstration of the new Field API (CCK rolled in the Core Drupal API).

When you install Drupal 7 beta 3,  the system is pre-configured with several base field types (e.g. Decimal, Boolean, Integer, Image. etc). An adminstrator add one of the forementioned field types to a content type (e.g. Story or Page) and thus create a "custom" content type. An admistrator simply uses the adminstrative user interface (web forms) to create a custom content type. So far, no programming required.

For our example, we decided to add a new field type, using the new Drupal 7 Field API. We decided to call our field "News Date". It's a simple field that is stored in the database as an integer (number of seconds), The field is displayed in M-d-Y format (e.g. Nov-17-2010). When you create or edit the "News Date" field, the system displays the standard Drupal 3 drop down combo boxes (month, date, year).

To create our module. we start by creating a new folder (news_date) with 3 files: news_date.info, news_date.install and news_date.module. 

In this post we'll modify the standard "My Account" user/profile menu and edit forms. We'll code the routines that allow users to edit their own "my profile alias".

In out previous post we discussed the fact that an administrator can turn this feature on or off. In other words, our code needs to check to see what the current system settings are before we allow a user to edit their alias.

First lets add our menu item. Note, we are appending the standard path "user". The following item is added to our hook_menu() impementation:

In this post we are going to add a configuration page for the system administrator.

Our "My Profile" project has grown. So far the system is set up so that logically and administrator performs all the work. The design assumption so far has been that only a user granted special permissions can edit or delete "my profile" records. A new user is allowed to enter their "my profile alias" when they create an account. However, we haven't facilitated a user editing their alias at some later date.

In our "proof of concept" module, we employ ajax to perform a partial page repaint. The following are screen shots of the "proof of concept" module (my_color). We demonstrate the initial form and report state, invalid data entered and finally valid (success) data entered.