I've got a nodequeue 2-rc about ready to go, and I just realized that I need the database stuff translated to pgsql. Anyone postgres friendly want to take a crack at patching the .install file?

Views 2 is proceeding apace, mostly on the weekends. With the baby I'm just not having the time throughout the week to actually work on it, which is unfortunate. But I thought I'd share with the world at large some of the things that are going on under the hood. This might be especially interesting to people who have utilized the Views API in the past; I decided to go for Drastic Changes.

These are my high level design goals for Views 2.

Views 2 will be the Drupal 6 port. Views 1 will not be ported to Drupal 6; this is so we can make wholesale changes to the API at the same time there are other changes, reducing the number of complex upgrades required.

The actual code in phptemplate.engine has been vastly reduced, and much of what it does has been made inherent to Drupal. The PHPTemplate renderer has been made the default renderer. As of Drupal 6, the primary purpose of a theme engine is to tell Drupal to use a different renderer (and, if they like a different extension. i.e, .smarty instead of .tpl.php).

I've long been of the belief that Drupal's love/hate relationship with Object Oriented programming is kind of an odd situation. Most of the time it's not really a problem, but sometimes we come so close to using OO methodology that it seems like a waste that we're not simply OO. One of the places that really shows up is the Forms API.

The design of the Forms API is exceedingly OO; but we're not using OO at all. I spent a little time thinking about it, and I knocked off an idea of what the current Forms API might look like if it were OO.

But this time, you don’t have to download a snippet.

First, I know a lot of people don’t really understand what the phrase means; and in fact it can mean quite a few things. Really all it means is that they are dynamic menus of some sort. In this case, it takes the standard Drupal hierarchical menu structure, and modifies it so that when you click on a parent item, instead of going to that page it opens the menu beneath it. (This has a drawback; that page is now inaccessible, but it can be revived).

To actually see this in action: try the demo site http://dhtml.demo.logrus.com/.

Khalid gives us a great recipe for combining CCK, Views and imagecache to create different sized images in different views. This is an interesting look at the power available when combining CCK, Views and enough knowledge to manipulate them to do what you want, not what they want to do.

Thanks to KarenS, who has become a very prolific Views’ contributor, we finally have the calendar app I’ve been wanting. It integrates with Views beautifully, and it finishes the demolition of the archive.module that I so desperately wanted to be rid of. It is the last piece, and now Views + Calendar can do everything archive.module did — and so much more.

Click here for a demo of the project.

So you have Views, and you've figured out exposed filters. Which, in short, gives nice handy little widgets to search. Often by keyword or by some taxonomy term.

Now what you want to do is put that functionality in a block. Say you're doing a catalog search or you have something you just want to always be up.

No Problem!

Panels 2.0 design

After giving this a great deal of thought, I have worked up a preliminary design for Panels 2.0. My primary design goal with this is flexibility, so that panels can be used in a variety of situations. The example situations I have come up with are the following: