Complaining about Drupal

Kindly allow me to bitch some more about Drupal. I'm a bit frustrated.

• Array parameters: just about every function in Drupal takes an associative array:
  

  array(
        'field_name' => 'publication_datum',
        'cardinality' => 1,
        'type'        => 'datetime',
        'settings'    => array (
          'granularity' => array (
            'month' => 'month',
            'day' => 'day',
            'year' => 'year',
            'hour' => 0,
            'second' => 0,
            'minute' => 0,
          ),
        )
      )
  

  
  This effectively defeats any auto-complete you might have had in your php editor. Of course I see why they did it; it makes everything 'neat', and it certainly is flexible. Except now you're not only unclear about what you should pass into a parameter, you don't even know the parameters. Add-on modules could look for any key, and there's no way to find out, except by proper documentation (which is rare) or poring over the source code.
  Distinct advantage for the lazy coder: if you need to send an extra variable, you can just hitchhike along with any array that's headed in the right direction if you make sure the key isn't taken.
• Template naming: do you want to override the rendering of a particular element? You could hook into a theme process function and mess around with the render array or whatever, but the easier solution is actually to give a template file a cryptic name with lots of dashes. This file name functions somewhat as a css selector: the more specific ones override the more general ones. Thankfully there's a module to help you pick a template name: Theme developer offers a plethora of  possible template names for each part of your page. That's pretty handy, but also indicates I'm not the only one who has trouble keeping track.
• The hooks! Oh, the hooks! There are hundreds of them, and you can go ahead and create your own if the fancy strikes you. Hooks takes different numbers of parameters, of different types (and with or without &), and there is no way to find out without, once again, checking the documentation or the source code.
  I know, PHP does not have strong typing, but the small amount of meta data that would otherwise be available is eradicated by kinda sorta duck typing that's going on in Drupal. Again: I can see why they did it, and it is even clever. But it's still frustrating.

The basic problem it comes down to is this: a lack of discoverability of features. When I'm developing a Drupal module I will have dozens of tabs open in my browser, looking for a clue how to use a particular module. Open source is good; it allows me to figure out what's wrong, even if I did not write the code. But just providing the source code is no replacement for proper documentation and sample code. It's just lazy.

Menno

Drupal 7 and Asp.NET webforms

I've been manhandled into writing some modules for Drupal lately. Weeping and gnashing of teeth abounds.
Php is not exactly my favorite language to begin with, and Drupal is extensive and complex and wholly alien to me.
One thing has struck me though, working through the Drupal hooks madness: just how much some of it resembles Asp.NET webforms. A recurrent criticism of Asp.NET has been its confusing event pipeline, and how WebControl abstractions give less control over the generated html.
But lo and behold: Drupal 7's "render array":

$form['taal'] = array(
    '#type' => 'radios',
    '#options' => array(
      'nl' => 'Nederlands (NL)',
      'en' => 'English (EN)',
    ),
    '#required' => FALSE,
    );

This generates a list of <input type"radio">. Change type to 'select', and it generates a <select>. It's also possible to pass simple html string into a render array, like a LiteralControl. The point is to be able to change properties about generated content from other modules, without having to do lots of string parsing.
And then I read in my "Building Drupal Modules" book about how you can hook into the rendering process to change things. Here's the list of available functions:

• template_preprocess()
• template_preprocess_[NAME OF HOOK]()
• [NAME OF MODULE]_preprocess()
• [NAME OF MODULE]_preprocess_ [NAME OF HOOK]()
• [NAME OF THEME]_preprocess()
• [NAME OF THEME]_preprocess_ [NAME OF HOOK]()
• template_process()
• template_process_ [NAME OF HOOK]()
• ... you know, forget it

Total of twelve, for one possible hook, and there will be lots of hooks - add six for each. This is also an event pipeline of sorts. It's just that event handlers can only be added by AutoEventWireup, and it's for everything, not just page events.

Mind you, I'm not criticizing Drupal. Whenever you aim to provide a flexible web platform, you will come up with solutions that have to be either complex, or not enough.

Still, pain.

Menno

About those animated ajax page loads in MVC ...

A little while ago I showed a way to chain animation functions with callbacks in javascript. That was part of a web site in MVC the requirements of which were as follows:

• It needs to use awesometastic animation prettiful swooping panel dynamified load superlicious "Html5" etc.
• It needs to do well in search engines, and
• work reasonably well in IE7

The animations were part of the ajax-loading of the page content, but -of course- people needed to be able to link to any page directly as well.

So here's what I did:

• I created a ViewConfig class. This class contains the current configuration of the browser screen: what menus are shown, which background(s) are showing, etc etc:

      public class ViewConfig
      {
          [JsonConverter(typeof(StringEnumConverter))]
          public MenuDisplay Menu
          {
              get { return _showMenu; }
              set { _showMenu = value; }
          }
  
          [JsonConverter(typeof(StringEnumConverter))]
          public BackgroundsDisplay Backgrounds
          {
              get { return _backgrounds; }
              set { _backgrounds = value; }
          }
  
          public string Root
          {
              get { return _root; }
              set { _root = value; }
          }
  ...
  

• I created a BaseModel class that includes a ViewConfig property (and my menu data and other data shared among all models):

      public abstract class BaseModel
      {
          public List<Business.MenuItem> MainMenuItems
          {
              get { return _mainMenuItems; }
              set { _mainMenuItems = value; }
          }
  
          public ViewConfig ViewConfig
          {
              get { return _viewConfig; }
              set { _viewConfig = value; }
          }
  
          [JsonIgnore]
          public string ViewConfigJson
          {
              get { return  _viewConfigJson; }
              set { _viewConfigJson = value; }
          }
  ...
  

• Each controller takes a boolean json parameter that determines if the Model will be sent to the view, or rather simply returned as a JsonActionResult:

      public class InhoudController : BaseController
      {
          public ActionResult Index(string taal, string inhoudId, string json)
          {
              bool returnJson = "true".Equals(json);
              Models.InhoudModel model = new Tabeoka.Epsilon.Web.Models.InhoudModel();
  
  ...
  
              if (returnJson)
              {
                  var jsonResult = new JsonNetResult();
  
                  jsonResult.SerializerSettings.ReferenceLoopHandling = Newtonsoft.Json.ReferenceLoopHandling.Ignore;
                  jsonResult.SerializerSettings.MaxDepth = 1;
                  jsonResult.Data = model;
  
                  Response.Expires = 0;
                  Response.CacheControl = "no-cache";
  
                  return jsonResult;
              }
              else
              {
                  model.ViewConfigJson = model.ViewConfig.ToJson();
                  return View(model);
              }
  

• In the pages I then simply send an ajax request, get my model as json, and move, step by step, from my current ViewConfig to the new ViewConfig, using supertastic fantalicious animations.

There are just two obvious drawbacks to this approach:

1. As you can see, I need to send my ViewConfig twice; once as a string for the initial ViewConfig when a page is loaded through a View. The second when the entire model is serialized to json. It's ugly. I could serialize in my View to fix this.
2. Worse: I have a bunch of html rendering code in javascript. Ideally I would be able to use the same template in javascript and .Net. I'm not sure how and if that could work though.

Search engines and javascriptless (or javascript-poor) clients, I can just present a static version of the site. Other browsers will automatically have links on the page 'ajaxified'.

Conceivably in the future I can take this approach, and improve it by POSTing my current ViewConfig in my ajax request, build the exact delta between that and the requested page, and only fill up my Model with data to the extent my ajax code needs it.

Menno