Opinion

One of the things I like best about Drupal is the fact the code works like a framework. Things go together easily and are fairly easy to understand. So when I saw the release of the Zend framework I thought first to do a comparison of it against Drupal. Since Drupal beta 4.7 is out I took a look at it first. There are some new things in Drupal 4.7 like an AJAX library, Forms API and and now a file cache.

In my reading of the Drupal code I noticed immediately that I no longer could see the connection between things. This is something that you get used to when developing in Drupal, the core is not connected the same way twice. So I spent sometime first going through the Forms API and some new database flow. Forms API is neat and tidy and useful in comparison to the older forms functions. The thing that disappointed me was that now the code is spread out all over hell. I could not pick up the thread of how things flowed. Immediately my mind turned to OOP. There would not be such a problem if a class container was used to restrict all the functions in a single area. Trying to do this with includes works but it is confusing because there is no consistent code flow seen when reading. I gave up and settled on just knowing how to use the API to create modules and not knowing enough to actually modify it or debug it. This is a shame because this is the same problem that I have with ezPublish. Using and developing for ezPublish is okay. But I don't pretend to know how it works. I don't think anyone but the originators of the code do either.

On to something else. I saw that that Drupal uses file caching now which is something that I know a lot about. I use this type of caching in most of my own PHP CMS work and have used it several times for clients that wanted cache search engine results. Drupal 4.7 has this but Drupal 4.6 does not. So being the happy coder that I am I thought why not take an evening out and backport the file caching code? Hmm, This was not a good idea at all. I was lost after reading through the bootstrap.inc file. For some reason the code did not seem modular any longer. Again I found myself wanting to dig into a class object to find out how the methods worked. But there is no such thing in Drupal. What happen was that there were small changes being made to functions in other files besides the bootstrap.inc. These changes did not seem to make sense from a coding perspective. I know why they have to be made but I had no idea as to what the code flow was so the logic was lost. Suddenly I was coding blind. I turned on Active State Komodos debugger and tried to catch the flow again. No luck. The setting of cookies and placement of cache functions was not something that Komodo could tell me about.

I took a careful look at Drupal 4.6 and then went back to Drupal 4.5 for an hour or so. They were easy to work with both of them. I could easily find where the code was going even in more complicated modules like e-commerce. Working from the core out to make changes was also light work. I tried to make some simple changes in Drupal 4.7 and got stuck several times because five or six new functions just jumped out. I went to drupaldocs.org and read up quickly and tried to make some sense. But there was just too much information to take in and remember. After the tenth function I stopped.

This is the thing about frameworks. If they are small and useful then people love them and say they are the best thing since sliced bread. But when they become large an unwieldy then you learn to hate them. A developer may love the fact that they do not have to write a function from scratch. But they hate the fact that they cannot understand how the finished function works or how to modify or emulate it if need be. This is a major problem with working with ASP.NET. It is just too damn big to work with without an IDE to tell you what is going on. Recently ezPublish released a PHPedit component proving that PHP frameworks are not immune to this either.

Typo3 is one of those large CMS frameworks that does not have an IDE and is very intimidating to work with. It is just huge or as we say in this branch "powerful" and "robust" which are just cover words for "difficult". Now suddenly Drupal seems to be on the verge of becoming like other "robust" CMS frameworks.

Now I have only seen a few examples of the new Zend framework. The reason that it interests me is because it shows how simple things can be. But I also remember that ASP.NET started out simple. If Zend can keep simplicity of usage in the code so that it is just as easy to remember the framework as it is to remember PHP functions then they will have a hit. CMS software like Drupal will have to fight to remain popular because it will just be too easy to write things from scratch. CMS software built on the framework will already have an IDE. Most CMS projects dodged a bullet with Ruby on Rails because though it is easy to build with there was no hosting, ide or finished applications out. The same is not true for PHP. PHP has everything ready to go and Zend framework may just make things much easier. A CMS based on Zend Framework might boot the other PHP CMS projects to the curb for their lack of being easy to understand. This is of of course if Zend framework does not fall into the trap of trying to be the next ASP.NET.

This article brought to you by the Hiveminds Magazine - Staff. Contact us if you want to post an article or announcement anonymously