The Site Access Pattern and the Joy of eZ

By Deane Barker on August 19, 2005

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 functionaity 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:
    3. The same database
    4. The same settings as the public side
    5. 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.

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

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

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

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

Gadgetopia
What This Links To
What Links Here

Comments

  1. I got to thinking about this some more, and it turns out that this is simply MVC:

    • The database is the Model
    • The settings are the Controller
    • The templates are the View

    But what’s interesting is that you can mix and match. Most MVC apps have a single model, a single controller, and a single set of views. With eZ publish, you can have as many of each as you want, then mix and match them in response in inbound requests.

    Now that’s interesting.

  2. Deane, Tell me more! We have been thinking about writing our own CMS but then I’ve been reading your glowing reports about ezPublish. Now I’m going to work on ‘selling’ it to the rest of the office. What resources do you know of for learning ezPublish? Books? Tutorials? Anything would be helpful, especially since you said the learning curve is “near-vertical”.

    I figure if we try and write our own, to get it where we want it will take at least 6-months – 1-year, let alone continued development.

    Thanks…

  3. Sounds good. But personally I’m on stage “you -18 month”. I just started with the system and I’m hitting all possible riffs. The logic is weird indeed; documentation is very “thin”. Nothing on DB structire at all. Site search does not help much and takes a lot of time to go through the result and find the solution that already implemented by other people.

    Any books that you would recommend?

  4. documentation is very “thin”.

    They have a new documentation site that — for some reason — they don’t publicize too much: http://doc.ez.no/

    Nothing on DB structire at all.

    By design, likely. I have very, very little idea of how the database works or what it looks like. You really don’t need to deal with it. It’s more or less a black box.

    Any books that you would recommend?

    There’s only one book about eZ publish, and it wasn’t designed for beginners (it jumps into writing extensions by about chapter 4).

  5. This is a great summary of eZ publish. I’ve been using it to develop sites for almost 3 years and it is awesome. It does take a while to learn how to do things the eZ way but once you do it’s incredibly quick. eZ publish is not just a CMS but a framework.

    Nothing on DB structure at all.
    By design, likely. I have very, very little idea of how the database works or what it looks like. You really don’t need to deal with it. It’s more or less a black box. This is 100% correct – the database acts simply a persistence mechanism for the classes the structure is not important from a programming POV.

  6. You have to be kidding! The template language is positively the worst I’ve ever used!

    The learning curve was OK, the problem is the immaturity of the design. For instance, the template language doesn’t seperate cleanly between a query language and a layout language (like, you would do an XQuery to get the data but use XSLT to style it).

    Not to mention that you get the feeling it is all hacks upon hacks upon hacks… it works ok, but that’s just because of the massive amount of hours of stupid, brain-dead bug-fixing going into it instead of fixing the underlying problems…

    (puh!)

  7. Nowhere in my comments did I specifically address or endorse the template syntax or language constructs. My post was more about the overall architecture of eZ publish, which is amazing.

    (puh!)

  8. Same feelings than Dean. eZ Publish is incredible, and when you start to code your own extensions if becomes a no-limit cms.

    But it has some disadvantages :

    • poor community
    • no newbie 101 Tutorial
    • more than vertical learning curve
    • uses a lot of server memory if missused

    But I love it !

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.