Now, having some experience in trying to do database handling manually (e.g. having to use mysql_connect etc all the time) and letting Doctrine to do this for you I have one phrase to tell you: if you are not using ORM already you are losing a lot of precious time.

So, just as a small example of ORM godlyness. Really small and really simple. We need to create a page which holds orders from clients. Each order consists of items (duh!). This means two database entities - Orders and Items

First, let us see what we would need to do if we did not use Doctrine (or some another ORM):

• Create an SQL script for table creation (the main problem here is that SQL scripts are unreadable at all):
  • CREATE TABLE 'order' (id INT NOT NULL AUTO_INCREMENT, client_name VARCHAR(255), client_address VARCHAR(255));
  • CREATE TABLE 'item' (id INT NOT NULL AUTO_INCREMENT, title VARCHAR(255), cost FLOAT, order_id INT NOT NULL);
• Create classes Order and Item. This is always very annoying for one reason - you have to rewrite CRUD functions over and over and over and over again. I hate it. I am not going to write the CRUD support for those classes right now, but if you did it once - you do not want to do it again.

Well, that was pretty simple, but 1) time-consuming; 2) cofusing (you cannot see the overall scheme of things; 3) it is Boring.

Let's take a look how you can do this whole thing with Doctrine in no time. The basic idea is to create a YAML (*.yml) file, which describes your database scheme. Here is how our case would look like:

      Order:
        columns:
          client_name: string(255)
          client_address: string(255)
      Item:
        columns:
          title: string(255)
          cost: float
          order_id: integer
        relations:
          Order:
            local: order_id
            foreign: id
            foreignAlias: items

Voila. This is it. After that the only thing you have to do is type "php doctrine build-all-reload" in your favourite console and let Doctrine create the tables in the database and the classes for you. Right after that you can start using those to implement your business logic without caring about the CRUD functions!

In my script I could go like this right away:

      // Create an order and set its vars
      $order = new Order();
      $order->client_name = "Vasili Pupkin";
      $order->client_address = "Bobrujsk";
      // Add a new item
      $order[0]->title = "Saaremaa Vodka 80";
      $order[0]->cost = 15;
      // Add another item (which plays very well with the first item)
      $order[1]->title = "Good pickles";
      $order[1]->cost = 2;
      // Save the order to the database
      $order->save();

And that is the end of that story. Create a YAML file and start implementing the business-logic instead of spending a couple of hours (or more) writing boring monkey-oriented code.

This time I am going to go a bit deeper into minuses of MODx. Why? Well, all the pluses are available on the official website and I do not see the reason for repeating those. This post does not in anyway mean that MODx is a bad product! It just has some bad sides that I would find very useful to read about before starting to build a website based on this system. This post is healthy citicism and maybe a precaution for those wondering what can't you do with MODx.

1. Documentation

One of the most important minuses I have noted about MODx and anything related to documentation. Well, it is horrible. That concernes practically eveything. MODx heavily relies on customization by adding such things as chunks, snippets, plugins and modules. Not only the documentation of the MODx core system is horrible (and can be shown as agood example of how to not write documentation) but this practice also concerns anything starting from snippet usage to writing your own MODx components.

Now, I undertand that MODx did not even hit version 1.0 yet, but this (boring) part of any project is crucial to its success as the will to start using any framework-like product mostly depends on the features offered (50%) and documentation (50%). This is obvious and I do not understand why the MODx team is not concerned about this.

In the end I found myself googling such things as "wayfinder placeholders" and "ditto parameters" every now and then, since I keep forgetting those details. In addition to that all the documentation is done in different formats and designs, which is very annoying.

As a solution it would be not so hard to make some kind of a public documentation repository available to the MODx contributors with unified rules about documenting their code. Some kind of MSDN for MODx (not that complex of course).

Or as for now (e.g. until the 1.0 release) there should be at least a unified refence on all bundled MODx components!

2. Administrating area (manager) customization

At the moment the admin zone of MODx is pretty much monolithic. It cannot be changed fundamentally. And this is a major drawback, since admin zone is a vast part of the website itself. You cannot hide all of the stuff here and then, you cannot make it look too user-friendly after all (yes, I know about roles, groups etc. - it is far from ideal). Adding new custom functionality to the admin area can be done through modules, though the only place you can actually add this functionality is to the "Modules" menu (I get the logic, but I do not get why is there such a limit?).

The admin area must be fully customizable. Every single piece of it. Without editing the core MODx files.

* Many MODx people can, of course, say that there is MODx Revolution (which looks very promising), but at this point I will not discuss anything connected to it as the latest alpha was very buggy (right from the start) and unusable.

3. Templating engine

As already said in the previous post about MODx, the templating engine is quite far from being perfect. It has most of the necessary features, but far from Smarty by its functionality. I, personally, lack logical constucts ({if}). BUT! The behaviour of the templating engine can be changed. You can hook into the output event and modify the output as you wish (e.g. implementing as {if} would be quite easy, in fact, I have done it already as I cannot live without it and I do ot know how people use MODx without it - this simple plugin will be available as soon as I have time to make it look pretty).

Again, there is NO way you can mimic Smarty {if} with snippets - they simply work on a different level of MODx.

Conclusion

To conclude... Well, MODx is still pretty solid CMS system, which offeres a lot of features and works as a charm if configured and used corectly. Its disadvantage in the documentation area is, obviously, an effect of its open-source nature. The templating engine problems can be solved by creating a plugin (although it is quite strange to me that Smarty-like features are not present in MODx). Therefore, the only major problem at the moment is the manager customization. This problem is promised to be fixed when Revolution hits the ground but from what I've seen in the latest alpha it won't be a reliable product in near future. Therefore - modules are the only way to affect the admin area without going inside the core files of MODx.

0. Intro

Today I am going to say something about MODx CMS.

At the moment I have used it to make one website as well as I am using it right now to make another. This is mainly the suggestion of the client, so I am using it not because I like it so very much, but just because of circumstances.

So far my experience with it is, actually, quite pleasant. MODx CMS has a lot of fine features. At the moment I can tell that it at least has the minimal things that are required to make a website. So far I have understood, that most of the MODx functionality relies on the following things: templates, template variables (TV), chunks and snippets. All the other things are quite auxiliary.
So, let us take a look and see what those are.

1. Templates

Templates are templates. I think that any PHP programmer should be familiar with the idea of those. OK. So what about the MODx templates? Well, I must say - MODx templates are not the best out there. And probably anybody who used Smarty (I am a fan ) will feel the same about the MODx templates. Imagine a situation - there is a template variable - URL of an image you want to show. Obviously your template code is something like this:

<img alt="MyTemplateImage" src="[*image_url*]" />

Very simple, huh? But what if the user leaves this variable empty? Then you will get the following code:

<img alt="MyTemplateImage" src="" />

Which is horrible! Absolutely horrible. This leaves two options:

1. Make the user input the whole <img ... /> code.  Though this is unacceptable, since most of the client I met do not have any idea that there is "markup" in the world.
2. Do not show the image at all

So, basically what I am trying to say is - there are no logical operators in templates by default! Yes, by default. There is a add-on called PHx (Placeholders Xtended), which makes this thing possible, though the syntax is horrible (I guess due to the MODx template syntax). Take a look at the solution of our problem:

[+phx:if=`[*image_url*]`:is=``:then=``:else=`<img alt="MyTemplateImage" src="[*image_url*]" />`+]

And of course, just as a comparison, the beauty of Smarty:

{if $image_url neq ""}
<img alt="MyTemplateImage" src="[*image_url*]" />
{/if}

This is what makes the difference. In MODx+PHx I would have to use a workaround to solve this. And if I have a larger chunk of code - I would have to separate it into a chunk.
Now, you might have the impression that I hate MODx. That is not true. At the moment I am trying to point out some of the bad sides I found.

2. Tamplate variables

Template variables (TV) are custom variables you want user to be able to insert into the page template. E.g. the [*image_url*] in the previous part was referring to a TV. You can create a new TV in the manager area of MODx and then assign which templates have access to that variable. Right after that any page using one of those templates will have an additional field below the content editor, where the user can change the TV content. In our case with [*image_url*] we would want to set it's type to Image and the user will have the opportunity to upload an image or enter a URL of an existing image. The image TV will also have a nice preview. A nice way to help simple customers adjust the appearance and/or the content of the website.

3. Chunks

Now it is time to talk about chunks. What are they? They are simply chunks of HTML code that make the templates look neat and clean. E.g. usually in a page you would have a header, a sidebar, content space and a footer. So this is what chunks are made for (basically) - you put those parts into separate chunks and then your template itself looks like this:

{header_chunk}
{sidebar_chunk}
<div id="content">[*content*]</div>
{footer_chunk}

So this is a matter of neatness and separation of different page areas. Besides that - chunk are small templates themselves. This means that you can use other chunks within them, you can use variables and snippets. I like the idea and implementation of these.

4. Snippets

Snippets are like chunks. Except that they are mostly used with PHP code. E.g. if you your website to show current date - you will not use a chunk, since it must not contain any code. You would create a snippet, which returns the date. There are a couple of snippets that are really useful that come in the default package of MODx. Such as Wayfinder (can generate a menu for example), Ditto and Breadcrumbs. And, I actually do not know what else can I say about them

5. Conclusion

In the end. I want to say that the overall feeling about the whole MODx CMS was pretty Ok. It has everything to be a nice CMS for a website. Quite an easy installation procedure, some fine-tuning capabilities, templates and so on. I would definitely advise you to at least try it out and decide for yourself if you want to use it or not.

I would say that MODx CMS is almost ideal for small corporate websites. For larger projects it would require more tuning and messing with add-ons (e.g. PHx). It can also be a pretty good blog engine (I tried it out, but requires a lot of tuning if you want a feature-rich blog), though I would definitely use a dedicated blog product like WP for blogs (and as you can see I am using WP) .

Thanks for your attention. Post comment if you have any.