To those who aren't drupal geeks, I apologize. The last run of blog posts has been... well... Terribly Drupally. And unfortunately, that's not going to change for a bit. There's lots of fun stuff to blog about, and Catherine and I are having adventures, but right now it's getting close to Drupal's autumn code freeze and it's time to get geekier. So without further ado, the solution to the node rendering connundrum presented in my last post.

In it, I outlined the problems with the current node_view() system and nodeapi's 'view' operation. Like the old pre-Drupal-4.7 form building functions, it slaps together HTML chunks and spits out a big one. Dealing with things on a more granular level just isn't possible. This makes things a hassle for themers, and completely breaks certain modules (like the popular inline) when themers try to work around it.

Fortunately, the solution that we built for form rendering in version 4.7 is also the solution for node content. It might not be obvious, but our form rendering infrastructure is really designed to operate on any kind of content stored in nested structured arrays. The bits of data can describe file attachments and recipe ingredients just as easily as radio buttons and dropdown boxes, our core rendering function just eats the arrays up, calls the specified theming functions, and spits them out. Adrian and the other FormAPI gurus designed it with generalized content-rendering in mind, but weren't able to get those features into core in time for 4.7.

Well, now it's time: there's a patch available for review that changes the node module to use intelligently structured arrays for its content rendering.

How does it work? Moshe from #drupal asked me to blog a bit about it, so... here goes.  Continue reading...