[drupal-devel] Re: Allowing non-techs to do cool things

[Dries Buytaert]

>     Thinking by analogy with Unix, there's many more people who
> write interesting and useful shell scripts than there are C 
> programmers.
> The power of being able to script things together avoids the
> need for a good number of programs, and a good deal of programming.
>
> So, programming may not be for everyone, but the right system design
> can let non-programmers do what they need, allows programmers
> great control over their code, and extends the reach of any given
> program to applications far beyond what the original scope might  have
> been.
>
>     (But yes, we do shoot ourselves in the foot sometimes, too :)

Gotta agree with Djun.  I wouldn't be able to use Linux/Unix without 
being able to "stitch" a few commands together and manipulate their 
output.  Writing small script or composite command lines really helps 
to get things done quickly.  Similarly, what would Apple be without 
Applescript?

Here is a concrete example: Drupal blocks.  Right now, we have a bunch 
of "per block visibility settings":

  1. 'Show block on every page except ...'

  2. 'Show block only on these pages ...'

  3. 'Show block only on node pages of type ...'

  4. 'Don't show this block when the throttle kicked in'

While these offer a fair amount of control, more than once I bumped 
into the limitations of these "visibility rules".  Concrete examples:

   1. I wanted to create a block that is only visible to certain users.  
For example, I wanted to write a block that provides help to _new_ 
users.

   2. I wanted to create a block that is only visible to certain user  
roles.

   3. Various people want to display the 'book navigation' block on the 
main page.  (This block is hardcoded only to show up when navigating a 
book.)

   4. I wanted to create a block that is only visible on certain days or 
times of the year. (The 'Christmass Druplicon' block would be a good 
example.  A 'Bugfix friday' block would be another example.)

   5. I wanted to create a block that only shows up when the throttle 
kicked in (and not when the throttle is deactivated).

To allow this kind of flexibility, we'd need to add various visibility 
settings.  And even after we added these, it won't be possible to 
control how these rules interact.  The current set of rules use 
implicit ANDs but maybe I want to use ORs or a combination of ANDs and 
ORs.

The result?  The block configuration page (1) becomes an "airplane 
cockpit" on its own and (2) even so, it can't take all possible 
configurations into account.

The solution?  Provide me a 70x8 textarea in which I can a write a 
block's "visbility check" using Drupal's APIs.  Examples:

   1. Only show block to 'authenticated users' that registered less than 
a month ago:
   return (time() - $user->created < x);

   2. Only show block one week a year (eg. around Christmas):
   return (date('W') == 42);  // only show block during week '42'.

   3. Only show block to users with permission 'X':
   return user_access('X');  // I'm using a Drupal API here! ;-)

   4. Only show block when looking at a forum topic:
   if (arg(0) == 'node' && is_numeric(arg(1)) {
     $node = node_load(array('nid' => arg(1)));  // I'm using a Drupal 
API here! ;-)
     return ($node->type == 'forum');
   }

--
Dries Buytaert  ::  http://www.buytaert.net/