The Site Access Pattern and the Joy of eZ

By Deane Barker • • 8 min read •
Author Description

A case study example on the seperation of content and presentation channels.

AI Summary

This post explores the author’s insights on site access patterns and how they relate to user experience. The author emphasizes the importance of understanding these patterns to enhance usability and effectively cater to audience needs, ultimately celebrating the simplicity and joy of an intuitive design approach.

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.)

Links to this – The Four Disciplines of Content Management November 24, 2007
All of the disciplines put under the "content management" moniker can actually be split into four distinct groups.
Links to this – On Posting Practices December 27, 2006
Aaron Mentele is asking about posting practices for people who blog a lot. But while the first part of my prediction seems to be true, I can’t say the same about posting getting any easier. Deane Barker tells me he spends 15 minutes on each post with the exception of an occasional chapter on cms...
Links to this – The "Named Content Views" Pattern June 10, 2006
By concentrating on the different "views" a content object may have, you can simplify your content templating considerably.
Links to this – Moving from Content Management to Information Management December 7, 2005
We tend to think of content management as being used to manage content that will be consumed by people outside our organization. However, it can be used for purely internal content as well.
Links to this – Your Interface is NOT Your Application May 23, 2006
The interface you interact with when using your CMS is only part of the picture. You need to be concerned with the API that lies under that interface as well.
Links from this – CMS's Should Manage Content, Not Display It February 18, 2004
A CMS that interferes too much with the display and rendering of content can drive you nuts.
Links from this – The Content Tree August 18, 2005
A while back , I mentioned the concept of a “content tree” in regards to content management. I cited this as a “functional pattern” and promised to talk about it more, but I never did. So, here goes – With every content management system (CMS) I’ve written, I always get back to the concept of a...
Links from this – Functional Design Patterns July 6, 2005
Applications have patterns – ways of doing things that have stood the test of time. These aren’t object modeling patterns , about which books and books have been written, these are…best practices for how to solve a particular type of functional problem. Around my city, you see a certain style of...