Enough said; bragging about MODx is not the purpose of this article. This article is intended for anyone who has done any website development on top of MODx (which is also a framework). You don’t have to think of yourself as a professional developer or anything like that. You just need to understand the terminology of MODx components, because I’m not going to explain them. Refer to the MODx documentation for that.

This article is about chunks and template variables (TVs), and how they love each other very, very much.

There are many different content types for TVs. There are text content types, which are just text fields and textareas. There are also content types like list boxes and check box arrays, which have multiple choices that need to be preset. When you set up the choices for these types of TVs, the syntax is something like this:

Display Name 1==Value 1||Display Name 2==Value 2||Display Name 3==Value 3

The value of a choice is very flexible; it can be a string or a number, or you can really take advantage of MODx’s facilities and use a chunk or even a snippet. Remember that a snippet is a bit of PHP script that you can pass variables to, which means that you can create a lot of intelligence in your system by using them. A chunk, on the other hand, is just a bit of HTML; you can’t pass variables to it, and it doesn’t process anything. A chunk is a chunk, and that’s it.

The Problem with TVs

In my time of developing with MODx, I’ve been able to experience some of the long term effects of certain choices that I’ve made. In the past, when I would set up multiple choice TVs, I would set numerous snippets as their values. The snippets would usually do something simple, like load up previews of the latest 5 articles, or format and display the entire article of the current document, or create a menu. Then on each page that used the templates that the particular TV was connected to, I could use those choices to tell my system what I wanted to display on that page. I started running into problems a few months later, however, when I wanted to change the values of those choices, so that, for example, the latest 5 articles might be formatted in a slightly different way. I expected that, if I changed the snippet in that choice for that TV, that every page that had that choice would consequently change the way that it formated the latest 5 articles. What I discovered quickly, however, was that MODx caches the values of the choices that you make for each TV under each document, so if I change the value of a choice in a TV, all of the documents will still have the old value cached. The new value will only be reflected on new documents; the old value will remain in the old documents unless I go back to each document, one-by-one, and deselect that choice, save the document, then reselect the choice and save again. Then the cached value will be reset.

Here’s a quick example. Say I have a TV called “SideBarContent“. The TV is a list box, and the choices are as follows:

Article Menu==[[Wayfinder? &outerTpl=`menuOuter` &innerTpl=`menuInner` &rowTpl=`menuRow` &startId=`6`]]||Comic Previews=[[Ditto? &tpl=`ComicPreviewTemplate` &display=`3` &startID=`45`]]

This TV has two choices, and the values of each choice is a snippet call. It will allow me to choose, on a per-page basis, what I want to show on that page, either the article menu or a list of comic strip previews. Good enough. But then a few months later, maybe I decide that I want to switch the template for the comic previews and change the number of previews that are displayed. So I go back into the TV settings, and change it like this:

Article Menu==[[Wayfinder? &outerTpl=`menuOuter` &innerTpl=`menuInner` &rowTpl=`menuRow` &startId=`6`]]||Comic Previews=[[Ditto? &tpl=`NewComicPreviewTemplate` &display=`5` &startID=`45`]]

I do this expecting that all of the documents that have the comic preview choice selected, will use the new template and show 5 previews instead of 3. What I will find instead, is that only documents that are created after this change will reflect the new values; all of the old documents will remain unchanged. This is because when the choice was selected for this TV in the old documents, the system cached the old snippet call with all the old parameters. This makes the system run a bit faster, but can cause problems when changes like this need to be made.

So what makes chunks so special?

So this is where chunks can become very handy. I said before that chunks are just bits of HTML markup; that’s true, but there’s more to it. I also said that they can’t process anything; that’s true too, at least not in and of themselves. One thing about chunks that makes them extremely useful is that you can embed snippets in them. When you do this, you give them all the power of that snippet. And in the case of setting TV choice values, you prevent the system from caching the snippet call.

So now I can set the TV list box up like this:

Article Menu=={{ArticleMenu}}||Comic Previews=={{ComicPreviews}}

In the ComicPreviews chunk, I can put the following snippet:

[[Ditto? &tpl=`ComicPreviewTemplate` &display=`3` &startID=`45`]]

Now when I select this choice in my documents, the system will cache the call to my chunk, which in turn calls whatever snippets are in that chunk. If I want to change the parameters of my snippet later down the road, I just go to my chunk and change it’s contents to whatever I want. This will produce the cascading effect we’re looking for; the changes will be reflected in all documents that have this choice selected, new and old.

The shoot-from-the-hip teacher would probably run out of things to say before the end of the first week. Nevertheless, there are some who may have chosen this teacher, and I don’t blame you. After all, who doesn’t love free time, am I right? Seriously, sometimes a teacher who can just sit down and talk about a subject matter like they’re just having a cup of coffee with you, can be much easier to learn from. I have had at least one teacher who taught casually and seemingly unprepared, but nevertheless effectively; that teacher was the best I’ve had, ever. Nevertheless, not only are the good ones an exception, they are also an illusion; just because a teacher seems like they haven’t prepared a structured approach, doesn’t mean they haven’t. I argue that any teacher who trains their students effectively, and equips them with the subject matter thoroughly, does so partly, even largely, through the process of organization and structure. Sometimes the best organization and structure will sneak up on you like it was never there.

So anyway, long-winded speech to make a simple point. Coding is a lot like teaching, you’re just not teaching a human. You are, however, teaching a computer, which knows far less than a human, and assumes far less as a consequence, which is both good and bad. You are also leaving a trail of information for other human teachers (coders) to pick up on later, and therein lies one of the primary reasons to make sure that you’re code is organized.

In the years that I’ve spent learning PHP, one of the major challenges I faced was deciding whether I wanted to continue learning PHP. I’ve heard a lot of criticism of the language in the professional developers circles, one of the primary criticisms being that it’s not an object-oriented language. To many PHP developers, this comment is like fingernails on a chalkboard. The PHP development community is predominantly made up of procedural developers who could care less that PHP may or may not be strictly OO, and they’ve made a lot of decent arguments for procedural development. Understanding the two sides of this debate can be tricky because, as would be expected, procedural developers are obviously going to argue for procedural development, and object-oriented developers are usually going to argue for OO development. However, among the arguments that I’ve heard that I consider to be the most objective, from either side, the verdict tends to be, that whichever method you choose should depend predominantly upon the project, and as a general rule, when dealing with larger development projects, the more that your methods are object-oriented, the better off you’re going to be.

When I first began understanding the concepts of OO methodology, I was just stepping into PHP5. I felt that PHP5 was pretty object-oriented, and I didn’t really understand what some PHP critics were talking about when they said it wasn’t (yes, many were talking about PHP4, but some were, even then, directing their comments toward PHP5). Since that time I’ve worked quite a bit with javascript, and having now made a decent comparison of the two languages, I have a much better understanding of what an OO language is all about, and PHP5 is not extremely object-oriented when compared to languages like javascript or ruby. Nevertheless, I still believe you can build a strong OO application based on PHP if you know what you’re doing.

One of the primary end results of object-oriented development, in my opinion, is simply organization. It just makes more sense, for example, to take all the code that pertains to the user and place it in a user object, rather than intermingle it with a bunch of other code.

There are many procedural developers who don’t use classes to organize their code into objects, but do use files to accomplish some similar organization. For example, they may have a file called user.php where they place all of the code pertaining to the user. This is a very positive step in the right direction. However, the level of organization when using classes is still far better. Files give you the advantage of code separation, but they are still missing the advantage of trails. For instance, if I have a class called user, and somewhere in my code I have to refer to a user, I do so by creating a user object, like so:

$user = new User;

Then, if I need to refer to the user’s name, I do that like so:

$user->name = "Johnny";

If I want to refer to a group that a user is in, I could do that like this:

if ($user->groups->member) echo "Welcome back, valued customer.";

And again, if I wanted to refer to the permissions of a group that the user is in, I might do that like this:

if ($user->groups->member->allowPublish()) {
    echo "Publish documents.";
} else {
    echo "Sorry, but you are not allowed to publish documents.";
}

This makes your code very easy to follow. Looking at the previous permissions check and reading from left to right, it’s fairly straight forward to understand what we’re doing, i.e. we’re checking to see if the user is in a group called member that is allowed to publish. Even better, looking at the last member of that call, allowPublish, we can tell it’s a function because it’s followed by a set of parentheses, and now we have a good idea of where the function is located, i.e. it is a method of a class that handles groups, very likely a class called “member”; assuming that we’re using sensible variables, we’re now on a fast track to fast tracking. If this were procedural programming, this function would most likely be sitting on a line by itself without any trail or clues for tracing, so the fact that it’s a function would be all that we would be able to deduce.

OO methodology is also designed to make your code much more reusable, because when executed properly it separates code according to its purpose. For example, perhaps you are creating a social news site which will allow your visitors to create accounts and publish news. For this project you will need to design various bits of functionality, such as:

• The code that allows users to register, sign in, and write news articles
• The code that sorts the news articles by category and publication dates
• The code that formats all this information for viewing on web pages

Now imagine that months after this project is completed and live, you are given the task of designing a photo gallery. This new project has very little in common with your prior project, namely user accounts, and perhaps some of the code that formats information for web pages. Trying to reuse your prior project to suit the needs of the current project is out of the question. If you want to reuse the user code and formatting code, you’ll have to pull it out of your prior project and begin building upon it afresh. If you built the prior project procedurally, it is likely that sifting out the pertanent code snippets is going to be confusing, because chances are you have intermingled user code with input code with publishing code with database code with formatting code. On the other hand, if you built your site using OO methodology, you’re almost certainly in much better shape. Applying OO methods to your prior project, you will have built a class for each bit of functionality, i.e. a user class for everything the user needs to do, a formatting class for all of the formatting that needs to be done, perhaps a news class for creating and accessing news, etc. To reuse the user and formatting functionality in your new project, all you need to do is cut and paste the user and formatting classes over to your new project. You might also need to sift out the few areas in the classes that access other classes; but if you’ve done a really good job with these classes, chances are there are little, if any, areas that do that. Reusable OO code done well means clip, paste, and go. Reusable code reduces your long-term workload, which will either increase your profit margin or make you much more competitive.

OO methodology is also famous for abstraction, because it makes it very easy to design generic objects with generic properties that can take on many specific forms during runtime. Anytime you define a variable in a class and outside of the functions in that class, that variable is understood by PHP as a property of that class. Also, any functions that you define in that class are understood by PHP as methods, or actions that the class can perform. These methods can perform their actions differently based upon how the properties of the class/object are defined. When a class is instantiated as an object during runtime, you can define a method for the class to define its own properties during instantiation, or you can define the properties of the object after instantiation from outside the object under certain conditions.

I can speak from personal experience when I say that OO methods have made my job much easier and quicker. In a future article, I’m going to take some time to explain my own approach to OO development in PHP.