So there has been a lot of blogging and documentation in the past about the "right" way to do AHAH in Drupal. I think these people make excellent points, provide good documentation, and are pushing these types of dynamic interactions in Drupal in the right direction. I think a lot what's out there about this "right way" to do AHAH in Drupal misses some critical issues, though. Maybe someone else has blogged about it already, but I'll share one pitfall that I learned to avoid while doing AHAH.

If you know me, you know that I work on a lot of Drupal sites. You might also know that SliceHost (now a part of RackSpace) is one of the most affordable and simple VPS hosting solutions out there. That said, you might not know that I run several of my own Drupal sites on a single SliceHost 256 slice (256mb ram, that is).

Since I put up my personal blog site using Drupal on a slice, I've noticed that the site, despite being very straightforward as far as Drupal sites go, was not performing very well (3-5 second page loads were common, 400-500ms before initial HTTP response codes). So, I decided to take a closer look to determine what was going on and try to resolve the performance issue.

Last month Chapter Three announced they were working on a Firefox plugin and Drupal module that would allow Firebug to talk with Drupal. As a Web Developer who uses Firebug heavily every day and who specializes in Drupal, this announcement from Chapter Three got me a little excited -- so I installed the plugin, enabled the module, and gave it a shot.

Any Drupal developer worth his salt at least knows of the Views module. The shear usefulness and time-saving nature of views has earned the module a place in every Drupal site I've developed. However, because views are stored in the database and their presentation is controlled by the views module itself, managing views between staging/live sites, handling updates, and tracking revisions become difficult issues when dealing with Views.

A few weeks ago I read a brief but interesting article by Jeff Whatcott on Getting Ecto Set Up with Drupal. I had heard of Ecto in passing but had never really looked into using it. With all the hubbub around WYSIWYG tools for Drupal and the like recently, I wondered if a good desktop application would be a viable solution, so I figured I'd give Ecto a try for myself.

A friend of mine has been using CakePHP to solve some problems where he works lately, and has been asking me for some help here and there. I always love to help as much as I can, but lately I've found my advice when it comes to CakePHP to be less helpful than it was in the past.

I recently presented at an event where several web application frameworks were discussed, including Drupal. Around that time I was also working on several projects written as Drupal modules at a level that I had not done before. These series of events caused me to take a step back and consider Drupal's merit as a web application framework.

This post is in reply to a comment on a previous article that I thought contained some good questions:

At work a few months ago, I was directed to started looking into some options for developing small database applications. So, I set out on my quest to find the best solution out there. Several weeks, and at least as many frameworks later, I finally found a solution that seems to work.