That works just fine for most purposes, but we may have to bring in content from not just outside the core Drupal tables but outside the core database, and even on a remote server through webservices. To this end we’ve decomposed the core user module’s user_load() and user_save() functions. This helps us understand better both the workflow and at what points in it our own code can motor into life, query all those extra resources (or set those queries in motion), assemble the rest of the user++ object, and then hand control back over to Drupal.

For those who don’t know much about Drupal, its core has a hook-based API structure. At certain points in its workflow, it checks all the modules for functions following certain naming conventions (typically the module name followed by the hook name e.g. mymodule_init on response startup, or mymodule_block to return details about the module’s support for Drupal page furniture). Any matching hook functions are called in the order defined by module weightings, and then page processing will generally continue: you can crowbar a grind-to-a-halt exit() in your hook, but it’d be unwise, as you can never be sure what tidying up Drupal might need to do after your hook. Outside these hooks, your code has little control over Drupal’s core functioning, unless you stub out entirely the bits of core you need yourself, and get your request to use those bits instead.z

Because of the way they let your code tag along with Drupal’s powerful core, hooks are essential to developing modules in the most Drupalish way. With that in mind, here are flow diagrams of the three basic aspects of user functionality—create new, load, save existing—lifted straight from examination of the code:

• Loading an existing user with user_load
• Creating a user: saving a new user with user_save
• Updating a user: saving an existing user with user_save

Although you have to save a user before you can load them, I’ve put this functionality first in the above (admittedly unordered) list. There are two main reasons for this:

1. user_save actually calls user_load a number of times, once or twice, to “refresh” the user object
2. user_load is a more primitive function and so bears examination first

Stripped down, user_load consists of: querying the database for a core user record matching the search criteria; returning this and the extended profile data; unserializing a free-data field and inserting it into the user object; discovering user roles; triggering hook_user('load') and returning the object (or boolean false, if no user found).

What this reveals (which I didn’t realise before) is that the anonymous user is in the Drupal users table, with ID=0. Otherwise, searching for this user would return no records, and the anonymous user object could not be instantiated. You could therefore attach rich data to the anonymous user, if you were in a hacky mood.

The two user_save workflows are fairly similar. Creating a user means obtaining an ID from the database: because some MySQL providers have poorer feature sets than others, referential integrity is ensured at the application level rather than the database level. In place of obtaining an ID, user update calls hook_user('update') to pre-process the user. Both workflows then set aside special fields, such as the user’s password, user roles and any profile fields managed by that module (determined from user_fields()). Then they save this data into the database in slightly different orders, with user creation calling hook_user('insert') early on, and the update procedure calling hook_user('after_update') much later in the process, just before determining the external authentication mappings (e.g. OpenID) and returning the user object.

What does this mean for us? Well, we’ll want varying amounts of data to piggyback on the core user object, so we have somewhere to cache it. Ideally this data won’t be summoned—brought out of the distributed data ‘cloud’—on every request/response cycle, so we’ll need to do some local cacheing, but not so much that we’ll get out of synch with the cloud (or that we’ll duplicate sensitive data). We think that, given the pair of hooks in user_save for existing users, we’ll have just enough leverage to do this: the first hook will effectively “tear down” our extra data, so we can do what we want with it, and store it somewhere temporarily; the second hook will “set up” the user for the rest of the request, by putting all that data back in. The existence of user_load within user_save complicates things somewhat, but at the same time it gives us some more wiggle room, because each call to that function fires another hook.

A Drupal hook is worth a thousand lines of module code, but they’re still a bit few and far between for some workflows. Hopefully the accompanying images will help anyone reading to find them, and ditch those thousand lines before they’re even written.

from django.conf.urls.defaults import *

urlpatterns = patterns(”,
    (r’^$’, ‘myapp.views.webroot’),
    (r’^a_page/$’, ‘myapp.views.another_page’),
    (r’^nothing_here_dude/$’, ‘myapp.views.this_view_does_not_exist’),
)

You have a fairly basic Django page which works; you add a new tuple to the URL patterns and refresh the page: it works OK, so if everything runs through the URL dispatcher fusebox, then it must be all right, yeah?

Unfortunately, nonexistent view methods seem to break pages that do a reverse lookup in the URL layer using the {% url %} template tag. You might not use this, but the standard Django admin interface does, several times, on its first page after login e.g:

<a href=”{% url django.contrib.admin.views.doc.doc_index %}”>{% trans ‘Documentation’ %}</a>

The above code generates a URL by comparing the view method to the evaluated second arguments of each URL pattern, and evaluation fails at the nonexistent method, giving the error:

ViewDoesNotExist at /admin/
Tried options in module myapp.views. Error was: ‘module’ object has no attribute ‘this_view_does_not_exist’

Sometimes this error isn’t thrown, so perhaps the underlying code searches a dict of URL patterns in no particular order: that would mean that every now and again it returns the matching view without ever getting to the nonexistent method.

The fix is to comment out the URL. But what if you’ve got a big codebase, and there are several people working on it, and sometimes nonexistent view methods just get committed? Testing can help here, specifically interface testing using the fake Client “browser”. That’s not easy when it comes to the out-of-box admin interface, though, because its login procedure seems to require both cookies and a hidden, hashed field to prevent automated logins.

This sounded like it was going somewhere when I started writing it; now, though, I think it’s just handy to publish it and let it have the Googlejuice, as I couldn’t find any references online to other people spotting this solution to a reasonably common problem that just—possibly because another view somewhere else was finally fixed—suddenly vanishes.

This is wonderful news, especially because the collection is being released through a slightly adapted version of Flickr’s existing website. This means, apart from it being an established interface that millions of people already know vaguely how to use, that you can do all the Flickry things with the photos—dedicated Flickr-heads will hopefully give a more qualified response in due course—and that third-party tools should already be set up to work with the content. The meta information storage won’t particularly excite any Dublin-Core enthusiasts—a block of unstructured HTML in the standard Flickr notes field, plus of course Flickr tagging—but the whole project is still a fascinating experiment, and interesting for even the casual observer of American history. How exciting does it get? More exciting than the World of Mirth Shows?

Thinking offline for a moment, this hopefully presages more leaps forward in MLA culture. One of the first would be to remove the “NO PHOTOGRAPHS” signs from all museums. At the very least such signs could be more honest, and instead read “NO PHOTOGRAPHS; unless our security guards don’t catch you at it, in which case we’ll be blissful in our ignorance. Anyway, in five years time it’ll all be online so we don’t know why we’re bothering, to be honest….” On reflection, I suppose they would need bigger signs.

Skip intro - or three types of copy the world will never miss

… Did you think I typed in your URL so I could watch a movie? Duh! I want information and I want it now. Only a fool actively erects barriers between a potential customer and his content…

I have a suggestion for a more user-friendly line of copy on the home page. It reads “Play pointless Flash movie that we paid a fortune for and are now desperate to have you watch.” Then the small children at whom these animations are so clearly aimed could sit there all day watching zebras turning into photocopiers while the rest of us get on with some work.

So writes Andy Maslen of Sunfish, in magazine trade publication InCirculation. I remember when I was doing my physics DPhil that a certain global electronics manufacturer (that also deals in household goods) lost thousands and thousands of pounds of business from us because I could never get past the Flash splash page. Fast forward six or seven years and lots of companies are still making the same mistake.

REST plays the same role as open source and open APIs: It eliminates tooling and vendoring as artificial barriers to adoption.

Interestingly, a corollary to this was brought up at Barcamp Brighton this weekend. During Gareth Rushgrove’s talk about REST and Nabaztag, a chap whose name I’ve again forgotten (although I’m sure someone like Fatty will enlighten me) pointed out that much of the push of SOAP is coming from the vendors, because the vendors make their money from selling tools, and REST development needs very few tools, most of which are free.

Undoubtedly there’s a set of problems that REST finds hard, but this truism is extended by SOAP vendors to the hard-to-prove (but also hard-to-contradict) claim that it’s a larger set, or a set more pertinent to enterprise solutions, than the set which SOAP finds hard. It convinces the consumers, because intelligent data mining and storage has always been a difficult problem, and a simple solution like REST feels like underkill for the job in hand. They let you confuse libre and gratis, the vendors point out (I see them sitting on the consumer’s shoulders with tridents at this point): so where’s the hidden cost of this free lunch?

(hat tip to Simon Willison)