By Deane Barker | December 3, 2005 | 9 Comments
When it comes to content management, custom fields are good — it’s nice to have a place to put things that the developer didn’t anticipate. You’d think it would bridge the gap between a “closed” CMS and an “open” CMS (see this post and this post), but it doesn’t really.
Having custom fields is better than not having them, but there’s still a problem: the custom fields are usually always global, meaning every object has to have the same fields. So I haven’t really increased the variety of objects I can store, I’m just able to store the same object with more detail.
So if I’m making a Web site for my church, I have a problem. If I use some of the fields for “Sermon Length” and “Biblical Reference,” these same fields are going to appear when I want to store a person.
Here’s a solution that I thought up while I was shoveling snow today (there’s a lot of snow, so I had a lot of time). This isn’t a replacement for a truely open, object-oriented solution (a la eZ publish), but it’s not bad. (The idea also creeps too far, as you’ll see.)
Here goes —
Instead of just providing some custom fields, allow users to define custom fields and group them into “Custom Field Sets.” So, I could create a Custom Field Set called “Sermon.” This would have fields for “Sermon Length,” “Biblical Reference,” “Sermon Series,” “Guest Speaker,” etc.
Then when I create a new post in TextPattern or a new document in Etimote or a new entry in Movable Type, I would “Add a Custom Field Set” to it. If this item is supposed to be a sermon, I add that set. For a person, I add that set, etc.
Problem solved. Sort of. There’s actually a slippery slope here. Slide with me for a bit.
Different items with different Custom Field Sets applied to them will expose different information. If I’m displaying a Sermon, then I have a piece of data for “Sermon Length,” whereas if I’m displaying a Person, I don’t. How do I expose that when I want to, and not expose it when I don’t?
The solution is to be able to select a template too. Etimote and TextPattern and lots of other systems allow you to do this on a per-item basis, so you can can pick a one-off template for a specific item if you like.
So now we have different templates for Sermons and for People that handle information in different ways. When I create an item and apply the Custom Field Set for “Sermon,” I should also pick the template for “Sermon.” And now we’re happy again. Right?
Well, let’s slip down the slope a little more —
The application of a Custom Field Set and the use of a template are pretty much locked together, right? If you apply the Custom Field Set of Sermon, then you pretty much always want the template of Sermon, right?
So let’s lock the two. You don’t just apply a Custom Field Set and pick a template, let’s apply an “Object Type,” which applies the Custom Field Set and the template together. Awesome.
But…why wait until you’re actually in the posting interface for this? Let’s do it before you get in there. We’ll have a drop-down from the menu that says something like “Add a Sermon [Person, whatever].” Rock on.
And, with that, we’ve just slid down the feature creep slide and complicated the crap out of everything.
I still think the idea has merit. I just don’t know when to stop.
What This Links To
What Links Here
Correct me if I’m wrong, but isn’t there a CMS out there that allows you to define custom content objects (posts, sermons, movie reviews, etc.)?
Yeah, I think it’s called eZ publish…but don’t quote me on that. :-)
Actually, Drupal can also do this. The Flexinode module is needed though, and with this you can define what fields your new node type will have, the order of them, which are mandatory or optional, etc, etc. It is quite powerful.
Why not just build a system on top of RDF, and add custom attributes to your objects that way? That would nicely solve the multiple schema problem. There’s a discussion of this on the semantic-web mailing list, and even MT support, in the form of MT::Redland.
I’m using Expression Engine to rebuild our church web-site. Expression Engine has “custom field groups”. In EE, you create a weblog (or section), assign a custom field group to it – you can also assign a “status” group to that weblog (for sermons I have status like “Text”, “Audio”, “Complete”). The template for that weblog can then refer to those custom fields.
Someone still needs to develop a plugin for the popular CMS packages to better handle/search Bible references.
I’ve heard nothing but good things about Expression Engine. Expensive, though.
Now granted I’m a EE lover (and get a volume discount on pricing)…but I always get puzzled over the claim that it’s expensive. I guess it depends on what you use it for…and I’m using it for business sites rather than a personal blog….but still…is $250 (or $150 for non-commercial, or $99 for a non-profit) for a pretty darn good CMS really expensive?
Heck…A copy of MS Word 2003 is $199 on Amazon.com. For one person to use. Or in terms of my hourly rate, I can’t do but ~3 hours of work for a client for that kind of money. Having worked with a few other CMS’s that cost in the 8-11K range, I’d put EE against them any day.
Huh…even checking it against MT’s pricing for commercial projects EE comes out favorably. EE’s commercial price of $250 is unlimited blogs, unlimited authors, multiple domains off one install, etc. With MT as soon as I’m over 5 users I’m at $349.00 ( and I really dislike user-based licensing schemes..:( )
I guess it depends on if you see it as a “highly flexible blogging tool” or a “pretty darn good content management system with roots in the blogging world”….but I’m starting to wonder if EE needs to make a greater effort to reposition itself in the market.
With regards to the slippery slope, it may not have to slide so far.
So what if it worked like this: You’re within the one blog and you’re about to write a sermon. You select “Sermon” as your category and the custom field set you want appears (a la Ajax or something). You fill in the relevant bits and click “Publish”. In your template, however, you just have some if statements and/or a loop which ensure the right bits get published. MT just cycles through each IfFieldExists-style conditional statement until all the fields are displayed. A cleverly-written template and matching stylesheet could provide something quite interesting.
As a result, you wouldn’t need to have multiple templates.
Greg, having conditionals is exactly equivalent to having multiple templates, except that it now involves merging them together with programming.
That’s more efficient design wise, but not simpler.