generic template design difficult w/o block region "look-ahead"

Well, I did find a way around this. Or rather I used PHP's output buffering to implement the second method in the original report (i.e., outputing all the blocks of a given region to a string and then checking the string to see if one should output it).

/*====================================================================*/ /**
  Returns the blocks of a given region as a string.

  @param string $a_Region the region who's blocks should be returned
  @param string $a_Theme the theme to use for the formatting callbacks
  @return string the blocks as a string on success (null if there were no
  blocks)
*/ /*=====================================================================*/

function theme_blocks_as_string($a_Region, $a_Theme)
{
    ob_start();
    theme_blocks($a_Region, $a_Theme);
    $blocksStr = trim(ob_get_contents());
    ob_end_clean();

    // Return null if there were no blocks in the region
    if ($blocksStr === '')   // Gamble? Only Drupal developers can tell!
    {
        return null;
    }

    return $blocksStr;
}

However, this does seem like a hack unless this method is officially supported in theme.inc. Here's why: if theme_blocks() ever changes the way it handles output (e.g., adds a ``<br />'' before/after the $theme->box(...) loop), then the conditional may break (and so will the theme). We try to be smart and use trim() to clean it up a little before we pass judgement, but this is not foolproof.

If this happens however (and we are duped into thinking we have blocks when we don't), at least the theme will err on the side of inclusion...it will just look weird to have a big blank column.

Now one can use this function as follows:

$blocks = theme_blocks_as_string('right', $this);

if ($blocks !== null)
{
    // Do your worst!
}

Actually I did see what you were doing before. I was trying to optimize for fewest number of database accesses to minimize load on a common resource (with Drupal, one can have a bazillion content servers running Apache, but I've yet to figure out a way to use more than one database server...I think this would involve rewriting a fair amount of Drupal's data access code).

I also figured that it would be unlikely for a theme to check for blocks in a given region without the intent to render them (so the rendering/computing isn't done more than once, it's just cached before being sent to the client). The rendering is only done once in both solutions.

If one is running a low-traffic site with a lot of blocks spread among different regions, your solution may be the winner. However, if one is running a very high-traffic site with relatively few blocks, the overhead associated with storing the rendered blocks is most likely less expensive than the database trip (probably around 1k per block). Both will work, it's really a matter of preference:

Method    | Advantages        | Disadvantages
- - - - - + - - - - - - - - - + - - - - - - - - -
ax        | no caching before | requires twice
          | rendering         | the number of
          |                   | database calls to
          |                   | render the blocks
- - - - - + - - - - - - - - - + - - - - - - - - -
matt      | no additional     | caches all block
          | database          | content in a
          | calls necessary   | given region
          |                   | before output

Perhaps an optimization is to cache the results of your query and only update them once every several minutes.

Keep in mind that the above is all hypothesis. I have no empirical evidence to support any of my claims.

I may have been confused to your original response. Yes, I did reread it and am probably an idiot (in which case, we've both implemented option 2 without extra database calls, but that leaves me confused about your added parameter to theme_blocks() -- do you call it twice?).

If you don't call theme_blocks() more than once per region, then they're equally efficient in the sense that no rendering is done (i.e., the while loop never executes) if there are no blocks returned in the database query. But yours avoids the added overhead from the output buffer.

One question: why do you make theme_blocks() call $theme->block()? Why not just rewrite $theme->box() to do what you want? Is there an object you're returning to stack up and use later when rendering? Just curious....