modules

In my session at DrupalCon DC, I promised an initial version of the Episodes module by March 15, which is today. I’m glad to be able to announce that I somewhat met that goal.

If you don’t know what it is exactly, I encourage you to read the project description first.

Status {#status}

It’s not yet completely finished: the basic reporting UI must still be written. But you can already look at the results of each individual page through the Firebug add-on (which I didn’t write, it’s already available). See the first screenshot for that. That’s of course much less useful, but it gives you a clear indication of the potential.
However, before I do that, I first have to work on making other deadlines for other courses.
So what’s done already? Here’s an overview:

AHAH-powered forms were virtually impossible in Drupal 5 (see the note though). In Drupal 6, this is much easier, thanks to the #ahah property. However, it still is really painful to actually use it.

The flaw {#flaw}

You have to write a menu callback for each AHAH-enabled form item of your form. You have to repeat small variations of this piece of code for each callback:

API {#api}

The API of the previous version of HS was a beast. Well, not the API, but the implementations. This has been fixed in version 2 of HS: it’s now much more elegant and much easier. If you don’t have to alter any forms, you can easily implement all hooks in less than a hundred lines, probably even less. The content_taxonomy implementation for example, is about 75 lines if you don’t count the form altering. That should make HS much more attractive to other Drupal developers.

Support Hierarchical Select Dynamically {#support-hierarchical-select-dynamically}

One of the low-hanging fruits is to support HS dynamically (i.e. use hierarchical select form items when HS is installed, use normal selects otherwise).

If your module provides its own hierarchical structure for which you want to use HS, you’ll have to implement the hooks. Next, I assume you have something like this in your form:

What is Hierarchical Select? {#what-is-it}

For those who don’t know Hierarchical Select yet, or HS in short, this is a module that provides a new form element. If you’re new to Drupal, you may just have frowned upon reading that. A ‘form element’ in Drupal’s Forms API is something like a button, select or textarea element in HTML, or a GUI widget in a GUI.

Now, the goal of HS is actually very narrow: making selections in hierarchies (hence its name) really simple: improve usability. The prime example and candidate for this is of course Drupal’s Taxonomy module. The idea is to first select an item from the root level, then pick one of its children (if it has any), then one of the children of the selected child (if it has any), and so on.

New and Improved {#new-and-improved}

There are many new features in version 2 of Hierarchical Select (or HS in short):

Almost 3 weeks two months ago now, I have released the Hierarchical Select module. (This post was originally written during the DrupalCon, but time has been sparse since then and bugs were there, which is why I’m posting this so late.) It defines a new form element: hierarchical_select. It makes the selection of something in a hierarchy much more usable. By default, selects of the taxonomy module (on node forms) are forced to use hierarchical selects - if the vocabulary is hierarchical. The same is applied to content_taxonomy CCK fields, when the select widget is used.
Note that the hierarchical select form element does not support the selection of multiple items. And obviously, it only selects the “deepest” item.
I’ll immediately skip to the demo, because a live demo says so much more than words.

And it has an API!

This part is only interesting to people who want to make use of this form element for other modules than taxonomy.

For one of the projects I’m currently working on, we needed to be able to store monetary values. This seems utterly simple at first, but there are many details that need attention.

The obvious one: multiple currencies. Luckily, this was easily solved by using the excellent Currency module, which includes a Currency API module, written by Khalid Baheyeldin of 2BITS. The tricky part is the ability to read from and write to different number notations (and thus store the amount notation-independently). The number one thousand for example is written like 1,000 in the U.S., but it’s written like 1.000 in Belgium. In the U.S. they use a dot as the decimal separator, in Europe a comma.
The default decimal separator is the comma and the default digit group separator is the space, this is conform with ISO 31-0. A function to parse numbers (the most difficult part) is absent in PHP, one to format numbers however, is present.