The Site Access Pattern and the Joy of eZ

I was working on a somewhat complex eZ publish-powered site today, and I acknowledged an important point that makes eZ publish – in my opinion – perhaps the greatest CMS ever built –

eZ is built around the concept of a “site access.” The way the system looks at it, a “site” is just a combination of three things:

1. A database full of content

2. A bunch of settings (which includes all the users, roles, and permissions)

3. A bunch of templates

eZ lets you assemble these three things based on the incoming request. What this means is that you can look at the same content (element #1) in completely different ways depending on elements #2 and #3. Different combinations of the three elements can render completely different results.

For example –

The way we usually set our sites up, the “admin” subdomain gets you to the administrative side of the site – the “admin” site access. Anything else gets you to the public side of the site – the “public” site access. So you configure eZ to know that the “admin” site access should use these three elements:

1. The database (there’s only one, so this is the same for every access)

2. The admin settings

3. The admin templates

If you come in on the “public” site access (anything other than the “admin” subdomain), you get:

1. The same database

2. The public settings (you’re automatically “logged into” the “Anonymous” user account)

3. The public templates

So the “admin” side of the site just looks and acts different from the “public” side, but it’s built on the exact same platform. In fact, eZ doesn’t even know that the admin side is the admin side – it just knows that it needs to use these templates and these settings, and what comes out is an administrative interface.

This enables a number of really handy features –

1. It makes talking about the “admin” side and the “public” side a little nebulous, since they both happen to just be a site access. When I say “admin side,” I’m really saying, “a site access that lets you administrate the site.”

   But the line blurs. The “public” side can expose some “admin” functionality – like the ability to accept incoming content. If you take comments on your eZ-powered blog, those comments are entering the system in the exact same manner as articles you enter on the “admin” side. (Which is great because then they’re exposed to all the functionality you normally only associate with administration – triggers, workflow, versioning, etc.)

2. You can create other “sides” to your site. You could configure the “xml” subdomain to use:

   • The same database
   • The same settings as the public side
   • A bunch of templates that render XML

   Voila – an XML interface. You could probably create a side that spoke the site aloud in monkey screeching, if you wanted. As long as you tell eZ how to assemble the three elements, it couldn’t care less what comes out.

3. The developers of eZ publish had to eat their own dog food when developing the default admin interface, since it’s rendered using the same architecture and the same templating language as the default public side. I’m quite sure the designer who put together the default admin interface really pushed the developers who were writing the template engine, since he had to use it himself.

   Not surprising, the templating language is very, very good. The developers didn’t “cheat” (for lack of a better word) and develop the administrative interface with a different, more powerful language than the one they’re making you render the content with. If you can see it on the admin side, you can do it just as easily on the public side.

   Not only did this improve the language, but it improved the core API, since if the eZ developers wanted to get at some functionality on the admin site they wrote, they had no choice but to expose it in the API. They didn’t let themselves “go around” their templating language, so they had to make sure it could do absolutely everything you might need.

   (I used to hate templating languages. I talked about this in a post entitled “CMS’s Should Manage Content, Not Display It” about 18 months ago. What’s funny is that the CMS I complain about – but don’t identify – in that post is eZ publish. Obviously, I’ve come a long way since then.)

4. Changing the default admin interface is easy because – as we noted above – it runs on the same template code that you’re using to write the public side of the site. If you don’t like how the list of articles is generated, change it. It’s not hacking – it’s designed to work that way.

   (It helps too that eZ has a beautifully designed override system that lets you selectively change certain things without hosing the default templates, so you can always go back.)

5. You can run completely different domains off the same eZ install. Just set up your site access so it connects to a different database (element #1).

   What gets interesting is that the site access could re-use the same settings and templates (elements #2 and #3) as other sites, so you could crank out a ton of templated content-based apps. Or they could use different templates and settings too, ensuring they were completely different.

6. Every “side” of the site is subject to the same security model. For the public side, you can just tell eZ to log everyone automatically as the “Anonymous” user.

   Since eZs permissions can be relative to the content tree, you can create a secured area on your site by simply revoking the Anonymous user’s “read” access to that area. The Anonymous user (which means, everyone who isn’t explicitly logged in) will be prompted for credentials when they try to access anything down that branch of the tree.

I’m curious if anyone can toss out other systems than run on the same architectural concept of a “site access” – systems which are oblivious to how their content is rendered and which don’t have a “hardcoded” admin interface.

And now here’s a blanket editorial statement that I know will cause outrage with someone. If you have thin skin, stop reading –

As I work with eZ publish more and more, I become more convinced that it is as architecturally perfect a content management system that has ever been built.

I have moments of brilliant enlightenment when working with eZ – I’ll be looking at some piece of functionality and think, “Why on Earth did they do it that way?” Then some angels start singing and a light shines through the clouds, and (1) I realize why they did it like that, and (2) I wonder why you would ever do it any other way but that. I am a better programming (in any language) for having worked with it.

Yes, eZ publish has some problems – the learning curve is near-vertical, and it’s tough to run it on a server on which you’re not root, to name two. But I will live with these problems because it is the best CMS I have ever worked with, and I’ve worked with a lot of them (including one that came with a $138,000 price tag).

Here’s why I know that I will never build another CMS –

1. I feel utterly free with eZ. I have never had to “hack” it to do anything. Perhaps a more important indication: I have looked at the database exactly one time. I probably couldn’t name a single table. I can’t say I care much, either.

2. When working with other CMSs, I would often think, “This is nice, but if I built this, I’d do A, B, and C a little differently.” Right now, if someone told me to build another CMS, I would simply build eZ publish over again, line by line.

I know that I am a serious content management geek because working with eZ publish is pure bliss, and that can’t be normal.

(After writing this entry, I believe what I’ve described is actually another pattern of content management, as it describes a design method that is language and application independent.)