Why is Ruysdael using MODx?
A few short years ago, I set out to create a software package that would post content on the web automatically, based on forms filled out by the website owner. It seemed like a fun idea, and it would help keep my programming claws sharpened. Several weeks into this part-time endeavor, I began to realize what a humongous task this was. The concept, of course, was easy, but the devil was in the details. And there were a lot of details. The project turned out to require far more time than I bargained for, so I threw in the towel and searched for a better idea.
Of course, the Internet is full of better ideas. There are a plethora of software packages out there - both commercial and open-source - that will take anything you write and post it on the web automatically. Having almost no money to throw at educating myself, I decided to experiment with some of the open-source CMS (Content Management System) packages. I set up a WordPress blog for my wife, and then I used Drupal for one of my early web clients. I then dabbled with Joomla and created a fairly nifty site, which is still running, despite the fact that I've been ignoring it for over a year now. I also studied a number of other CMS packages and read about a thousand blog postings about them. The bottom line was that I was spending about as much time studying CMS packages as when I was building my own with PHP. Seems the Internet is chock-full of information on CMS packages.
One of the things I learned was that choosing a specific CMS package can be as much art as science. The science part is easy - you simply need to know your requirements and then align them with the feature set. The art, however, is a bit more tricky. You have to develop a sense for whether the CMS will actually address problems in a way that makes sense for you, your customers and your business. For example, Drupal will create a nice navigation menu automatically, based on how you organize your material when you enter it into the system. God help you, however, if you decide to change how you organize your material once it's in the system. If you're not careful, you'll lose all your content! (Well ... it's not lost ... but Drupal will bury it where you're not likely to find it.) This type of experience can be unnerving and cause blind panic throughout your department.
Bottom line is that CMS packages exist along a spectrum -- at one end, you have packages like GoDaddy's Website Tonight®, where you fill out some very simple forms and get a somewhat generic-looking website. It's probably not going to attract a lot of viewers, but hey, if you just want to hang out your sign on the Information Superhighway (if you'll excuse the antiquated term), Website Tonight® may be the perfect solution. On the other end of the spectrum are packages that force you to write the entire CMS yourself, with the aid of a special PHP library, like Zend or Symfony, that can really simplify the process. So on one end of the spectrum, you have a rigid set of narrow rails, and on the other end, it's like free love, but with all the complications.
One of the better ideas I've found within my investigation can be abbreviated as "MVC," which stands for "Model, Viewer, Controller." MVC is a software model used by many of the more advanced CMS packages. MVC allows your web team to parse out different tasks to different personnel, depending on their strengths. The "Model" portion of MVC contains the content in an organized database. For example, every article written in a blog is actually stored in a database. The presentation of this information is not stored; only the content itself is stored. It doesn't matter if it eventually ends up on a web page, a PDF file, a mobile device or on an e-Book like Kindle or Nook. Content is content. It's the responsibility of the "Viewer" portion of MVC to show the data in a specific format. In a website, the "Viewer" ultimately renders the data into an HTML web page. But it could just as well render it to a PDF, mobile device, etc. Website designers normally work with the Viewer to render content in an artistic way so that the information looks pleasant to the reader. The "Controller" portion of MVC is the "back-end" code, usually written using computer languages like PHP, JavaScript, ASP or a combination thereof. Controller code is written by website programmers. With a CMS based on MVC, you can separate your artists, database specialists and programmers, allowing them all to work together, each specializing in his/her own field while contributing to the overall site.
In my search for the best CMS packages, I kept an eye on scalability, ease-of-use, flexibility and sensibility.
- Scalability - The ability to scale the website to any size without adding complications. For example, does it implement the 1000th page as easy as the 1st page?
- Ease-of-use - A shallow learning-curve for people who are not CMS experts. For example, adding documents to the site should be as easy as adding documents to a file structure. Just select a directory, add a file, and poof! The web page appears under a menu structure modeled after the file structure.
- Flexibility - The ability to change the structure of the site without a lot of pain. For example, your site designer can change the header graphics, sidebar content and menu structure without digging through code. Also, she should be able to format titles and provide "striping" for alternate rows of a table - again, without digging through code. Contrarily, your site programmer should be able to provide the ability to change content, graphics, and overall visual structure without digging through HTML. In other words, your site programmer and site designer should be able to compliment each other's work without having to step into the other's field of expertise.
- Sensibility - The ability to step back from the CMS and say, "Yeah, that makes sense." For example, structuring the content to look like a file tree simply makes sense. It is a familiar environment to those who are not accustomed to using a CMS.
In the overall spectrum of CMS packages, the four concepts above can only be accomplished by a package that implements an MVC model. Unfortunately, this eliminates many of the more popular CMS packages out there, including Drupal, Joomla and WordPress. These popular CMS packages attempt to get circumvent a lack of MVC structure by making site templates, widgets and plugins available. It's a vain attempt to get the website designer to wedge in slices of code that implement desired features. Problems arise, however, if the designer unwittingly installs plugins that are incompatible with each other or do not work with the current CMS software version. These incompatibilities result in broken sites. Other problems include plugins that don't do exactly what the designer wants; and therefore, she must settle for something that is less than perfect. Furthermore, programmers may hesitate to write custom plugins, as there is a considerable investment of time just to implement a simple feature. The result is that both the designer and programmer get stuck in a tar pit.
This is not to say that MVC is the proverbial knight in shining armor, but at least with an MVC architecture, the notion of separation of content from view is deeply ingrained into the structure of the CMS, making it easier to implement customizations. In my experience, MVC architectures tend to be friendlier work environments for both the site designer and programmer. Further, the isolation of the site's data (Model) makes it easier to render into multiple formats, allowing the team to work from one set of source documents and render to web pages, PDF, e-books, etc. MVC architectures tend not to put a lot of encumbrances on making modifications; rather, they allow the programmer to simply add his own code to the existing code base, and the site designer need only remember a handful of customized "tags" that will allow her to use this new code. With such a cleanly parsed environment, the workflow for web development teams is smooth and complimentary.
Some of the more popular MVC packages out there include Concrete, SilverStripe and MODx. Personally, I've investigated all three. I find them to be convenient to use, with relatively shallow learning curves. I've settled on MODx, however, based on the availability of the documentation for the API (Application Programming Interface). Since I am more of a programmer than an artist (and it is MY site, after all), MODx appeals to my sense of how things "ought to be." It scores high on my "sensibility" scale.
Regarding MODx, there are two flavors: "Evolution" and "Revolution". The newest version, Revolution, is more object-oriented and is rapidly gaining in popularity. (The site you're now looking at, however, is using "Evolution.") In either case, MODx implements a strong MVC architecture with a simple interface. If you are just starting with a CMS and are deciding to go with MODx, I recommend starting with the latest Revolution version, as it represents the future direction of MODx.

