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.

In example below we demonstrate some of the new Drupal 7 database abstraction layer features.

To add a record we are using db_insert(). "db_insert()" is more elegant than it's closest Drupal 6 counterpart (e.g. drupal_write_record). The method db_insert() returns the database key generated by the database.

In our hook_form() implementation, we added ajax attributes to a couple of our form elements. The example below is our ajax response handler. In Drupal7 you can use a simple response handler which simply updates a single element (not shown here), or you can send a batch of client side commands. Our example below sends a batch of client side directives.

We are using the Drupal7 implementation of theme_table to render our report. As of version alpha 6, theme_table() requires you to include at least 2 data rows (note! may be a bug).

In the example below, we check to see if we have any records to report.

If we don't have any records to report, we notify the user there is no records, create a default display.

If we do have records to display, we add the array elements to our $vars array structure.

Drupal 7 adds "ajax" attributes to the Form API (FAPI).

In our example below, we've added ajax attributes to our "report" button. When a user "clicks" on the button, we will send a request to a server side handler named "my_color_ajax_response". When the server side handler sends a response, we replace the contents of the html div element "report_table". We use the tag "id" attribute to identify the appropriate target html div tag.

Drupal 7 automatically adds database tables described with hook_schema. In our example below, even though we don't have an implicit hook_install or hook_uninstall method defined, Drupal adds the "my_color" database table when our module is enabled, and drops the "my_color" database table when our module is un-installed.

Drupal 7 introduces dynamic class loading. When you package your modules, you need to supply Druapl with a ".info" file. Inside the ".info" file you now declare an array of file listings. Drupal's new Module Registry inventories the file listings and dynamically loads method and objects as needed.

In our example below, we have have a file listing called "my_color_class.inc". The file listing includes several application objects. Before Drupal 7 we would need to use an "include..." statement in any other file listing before we could use those objects.

my_color.info