By Deane Barker on February 16, 2008

I spent some time this morning looking at PureEdit. It bills itself as a CMS, which is a classification I don’t know that I can agree with completely.

For the record, I only watched a couple of screencasts and browsed through some of the code. I don’t know if it would call it a CMS based on the definition we offered a few months ago, since there’s no higher CMS functionality: versioning, workflow, check-in/out, granular user management, etc. (PureEdit is, actually, every bit the “RDBWAAS” mentioned in the afore-linked article.)

What PureEdit is, however, is a nicely slick way of managing some database tables. Call it a very polished version of phpMyAdmin. It lets you, the developer, create a very usable interface to let non-developers manage database records of a database you created.

This is handy in a lot of ways, because there’s no over-arching data storage architecture to worry about (it’s your database, after all), and there isn’t any publishing architecture either — no templating or other stuff to worry about. You can just pull content from the database on the front end as you see fit, just like you’ve known how to do for years.

This is a nicely way to solve the problem we discussed a couple of years back: The Quandary of the Single Table Web Site.

What do you do with sites that need a single table of data updated? These are sites which are totally static, except for this one thing…

[…] This happens a lot — the sites are all static except for one element, be it a list of locations, events, the ubiquitous “Latest News,” etc.

What I like about PureEdit is that its datatype handling is pluggable, so you can think up a way that a user needs to manage a field, and the edit interface will present them with a customized widget for that datatype. (Example: you could plug in a Google Maps interface, have the user select a location from it, and then store the lat/lon information. This is something we’ve done for eZ publish, but it’s order of magnitude more complex in that environment.)

I also like that there’s no publishing mechanism. In my experience with content management, I’ve always felt this was the most wasted area of effort. Content publishing is vastly more simple than content management or editing (see The Value-Add Side of Content Management, CMS’s Should Manage Content, Not Display It and CMS Administration vs. Presentation Languages).

So, consider PureEdit a cross between phpMyAdmin and a full-blown CMS. It’s a nice, handy way to let non-developers manage tables of data.

It’s at version 1.1, and I’m excited to see where it goes. Add versioning, check in/out (or just simple record locking), and some more finely-grained user management (this user can edit records in Table A, but not Table B), and you’d really have a heck of a piece of work.

What This Links To
What Links Here


  1. Great write up! Thanks for featuring my CMS, PureEdit!

    I really enjoyed reading this article because I have struggled with myself to call PureEdit a CMS rather then a framework of some sorts.

    You could call PureEdit a “RDBWAAS”, but my goal was to provide developers with a quick stable solution to be able to streamline the development of the back-ends of their websites.

    You could argue that CMS’s have to have all the bells and whistles such as content locking, but in my opinion if a organization/company has so many users editing content that they need content locking, then they probably shouldn’t be using an open source solution — they need to buy into an 50k solution like you mentioned in “What makes a CMS”.

    I am excited just as much as you are to see where PureEdit goes from here!

    I appreciate the write up, keep up the great writing!

  2. Thanks for the write-up on PureEdit, Deane It feels similar to Django’s ModelForms. Django’s approach is entirely code-based (Python), but the end result is very similar to PureEdit’s.

    Does anyone know of a middle-tiered language/document (XML or the like) that stores this kind of model data? The namespacing in PureEdit limits it to new databases or database that can be renamed. Django gets around that a bit, but it still prefers to create the database tables itself. I’d love to see a document format (RelaxNG + something?) that would let one create models that could be moved between run time environments like Django or even PureEdit.

    Just an idea.

Comments are closed. If you have something you really want to say, tweet @gadgetopia.