The trouble with Blogs, Wikis, and Forums

There are a lot of great tools out there for blogging, wikis, and forums. Some of them even look nice and are (somewhat) friendly to use. I like wordpress, I like blogger, I like phpBB (except for the appearance), punBB, and others forum tools. I like wikis quite a lot. I’ve tried a lot of them recently.

But they’re all standalone. I got a googlewhack when I typed in “embeddable wiki” (not really, but practically the same.) It was a forum where someone was asking if there was an embeddable wiki. My definitive answer is “I guess not.”

That’s shocking. Does anyone not see the value in being able to create areas of content that are easily editable but are not the whole application?

Similarly, blogs and forums have this same problem. The prevailing philosophy tends to be to make your blog, wiki, or forum your whole site (you can usually make a theme for it) or build your site using an overarching product.

I was actually shocked that CMS apps don’t seem to have the idea of wiki, blog, forum, (and article) at the core.

The one exception is TikiWiki, which is quite cool, except for the code, presentation, and admin interface. It seems to have the right idea of what users want, but I couldn’t get past their admin interface, and didn’t really want to learn yet another templating and component mechanism (which by the way, seems to be done through their admin interface.) And it stores everything in the database! The clincher was that it’s hard to do pretty URLs (their rewrite setup is better than nothing, but not actually pretty) and the wiki editor isn’t actually that nice.

I may still end up using it for One Shore, but I really want the best wiki available, because I spend a lot of time in it.

Pivot seems interesting, in that it has a framework for file based blogging. That’s wordpress’s weakness. I want versioned files, not DB BLOBs.

Pluggable authentication is sometimes doable, but it’s always on some forum where a guy cut and pasted some code to get wiki X to use the same password database as blog Y or forum Z.

Like I said, the good ones are themeable (to a degree) and they have some of their own components, but what about my MVC or CMS components. Or how do I reference a blog post in a CMS?

Theming a blog is usually nicer than theming a CMS, but that might be because it does less. Theming forums is usually pretty limited. And theming a wiki is often a hack.

Most blogs (and some wikis) have comments, but not as fancy as forums. Thats okay, I think comments should be fairly simple.

Blogs, wikis, and forums all have in common that they’re web-editable blocks of text (preferably with limited markup). That means they’re files in my book. That also means that they should be components.

I want to include this valuable content on my site (not as my site). Something as simple as:

blogcomponent.display_post(blog_id, post_id, display_comments=no);


blogcomponent.standard_blog_layout(blog_id) or blogcomponent.rss_layout(current_month);

And files that can cross reference each other like this blog post:

[@title = You should see my wiki]
[@date = 20080303 094700 EST]
[@revision = 1.0]

Today I added a bunch of details about [this great tool | wiki:SuperFramework] in the wiki.

[Comments | forum:myblog:200803003-1_comments]


Of course, display comments should be in a configuration somewhere, and the comments link should probably be auto-generated.

And this should appear inside my site, without having to theme my blog (other than basic layout) or having to specify which menus or other components are displayed. The request would be something like:


To edit or create a blog entry:


The code for the blog page should be something like:

response.layout = site.content_layout #this includes all the menus, components, etc. in a normal content page

if ( request.inActions (“display_blog_post”) )

response.layout.add_component(components.content_component = blog.display_post(id, etc))

Of course this is bad pseudocode and the request processing should be done outside.

Optionally, if permissions allow it, I should be able to go directly to the file, and something like a raw content viewer would do:



components = fw.searchComponents(categories={‘blog’, ‘wiki’, ‘forum’}, regex=’/superframework/i’)

Anyway, the point is that I want components to work via code, not an admin interface.  I want all my content to be file  based and versioned, and I want components to access my content, and I want to do it via a MVC framework.  I want (pluggable/interchangable) hooks for things like authentication and persistence and helpers for things like session handling and database connections.  I want themes and layouts to be separate, and again code (file) based, though there’s nothing wrong with having an admin interface for selecting themes and layouts and components, and managing users, and publishing articles and other such workflow, though it’d be nice to have a nice UI for that admin interface.

The trouble with CMS frameworks

My last post was about the trouble with MVC frameworks, in my view, which briefly is:

Multiple action handling
Component/Template processing (related to the above)
Front controller/Back controller, helpers and the associated bloat or complexity and code duplication.

I noted that CMS frameworks attempt to handle some of this, most especially the component/template paradigm — usually by using the response wrapper paradigm.

I have two main issues with CMS frameworks:

  1. Working with them sucks and requires too much relearning and enforces a too rigid development process (see my post about leveraging existing knowledge and techniques.
  2. They usually have a very poor implementation philosophy, and don’t allow much reusability.

While I love looking at new MVC frameworks and learning their philosophy and coding styles, even if I don’t particularly like the framework, I usually walk away learning something (maybe that has to do with their code-centricness), I dread and hate the idea of looking at CMS frameworks.

That’s because it usually involves learning a truly awful administration interface, yet another template language, and possibly even a one off scripting language, and puzzling my way through an obscure (and often undocumented) series of conventions including file naming, manifests, api, and hacks for module building and using.  And they don’t make it easy to learn, because hey- they’ve got this cool, counter-intuitive, complex admin tool (website) that is their pride and joy that you should use instead.  Which works fine, if all you want to do is click “approve” on articles, add a menu or a weather widget on the right (or left!) side of the page, and have comments like slashdot (and a custom logo!)

So almost all CMS based sites end up looking almost exactly the same (depending on the CMS) but hey, you’ve got a lot of widgets you can include.  If your content is your main attraction, that’s probably okay.  You can find a whiz at making templates for your CMS to customize it if you really want.

But I truly do hate all the CMS admin interfaces in the world.  You spend as much time learning them as you do learning to code for an MVC framework.  Someone  said Django has a nice admin interface, but I’m skeptical.  Yes I’m going to look at it (someday.)

So you’ve got a lot of widgets, and you can even learn how to write them yourself, but because most of them were developed without OOP in mind, they’ve got weird, arbitrary rules and conventions that you need to learn to code them and load them.  The registering and loading of CMS components reminds me of the work set up EJBs (but hey, you’ve got a nice admin interface!)   But outside of self-contained widgets, there isn’t much flexibility.  Getting components to talk to one another is usually not worth the effort.

The other problem is the horrible implementation ideas.  I’ve already mentioned the non -OOP design.  You do not want to take a look inside most CMSes.  One of my favorites, TYPO3, is pretty scary.  A CMS is not meant to be tweaked (except through their handy admin interface!)

But my main source of frustration is that they almost universally cram all your content into a database.  That’s bad bad bad.  I do not want to author my site via a textarea (even if it’s TinyMCE) and I don’t want to lay it out via the amazing admin interface!

And I don’t want my templates to be one off monstrosities.  (Using one-off markup and scripting, no doubt.) And chances are that cool widget you want to include does:

printf(“<td border=2><font color=”red”><b>widget content</font></b></td>”);

instead of actually working with your theme.  Which you probably don’t want to touch to customize anyway.

This screams MVC separation.  I want widget content to be the widget.  And I want my controller to specifiy the parameters for the widget.

But how do you do that in the URL when you’ve got multiple widgets?  That harks back to my problem with MVC frameworks.  And you know what?  An admin interface(!) for an MVC framework would be nice.  I shudder to think of it, but the best idea (if not user interface) for that admin interface I saw was ATG Dynamo.

I’d like to leverage the content-centricness (and components) of CMS framworks, but I don’t want to deal with authoring all my content in a textarea and saving it to a database BLOB (and deploying it via their cool admin interface!)   I want to use components, but I want them to be simple STDIN, STDOUT type components.

This is where frameworks like CakePHP fall down I think.  The component development process for Cake is (I admit mostly ignorance) is as convoluted as it is for Drupal.  I think Zend does a better job, but I haven’t really seen a component market for Rails (again, I’m fairly ignorant), apart from things like the AJAX HTML component wrappers.  I think I actually prefer the CMS way of building a template via (bastardized) HTML than the HTML::Template / Struts style that Rails has adopted.

What I really want is a front controller that does a good job of setting up my resources (such as sessions, db handlers, etc.) as plain objects(!) and provides wrappers for things like authentication and action mapping, and then passing it off to my response handler after running my action chain (which uses simple MVC components) which then builds the page accessing the views, selecting the template, theme, passes in pure data to components (which pass back pure data) and uses my content objects — which are versioned files, not database BLOBs, and lays them out according to my specified layout and theme (separate objects) which are probably handled through my nifty admin interface!

It’s okay to generate content via a textarea – like for a wiki or blog  (or even a form) but it should be just as easy to upload manually.  As a matter of fact, that leads me to my next one:

The trouble with Blogs, Wikis, and Forums.

The trouble with MVC frameworks

Here’s the problem I have with so-called Model-View-Controller frameworks like Rails.

They seem geared towards a single application per implementation.

What do you do with a request that wants to work with multiple components? Or perform multiple actions.

Then a REST-style request such as


falls flat on it’s face, because you’ve either got a bunch of complex logic, or actions loaded as parameters:


You could get it from the session, configuration, or whatever, but then you end up coding in XML or whatever.

if (session.Y=true)


<component name=X>


<result condition=”success” action=”doY”>

And then you’ve got to worry about templating, localization, etc.

And you still need a front controller to handle things like user authentication, session management, request routing, etc.

You could have a page (request) controller extend a base controller, but it’d be nice to take things like authentication a la cart, and not need to load it on every request. Appservers handle this by loading everything and holding onto it, but this is resource intensive. You think a mod_perl app can get ugly, but pushing everything to tomcat, websphere, or mongrel gets just as ugly, though the separation is sometimes cleaner. FCGI forces you to separate your ruby out, but the temptation with mod_perl to put it all in the front end is dangerous. Or you end up on the other end, like so many java apps, duplicating stuff over and over in multiple layers of abstraction on multiple servers. You could just as easily mod_proxy to your mod_perl appserver just as easily as you mod_jk to tomcat or FCGI to mongrel though.

But back to MVC frameworks. How do you handle multiple action requests without getting ugly? And how do you provide helpers and components and templating without forcing one way to do things?

One answer is CMS frameworks: CMS being short for “admin user interface, layout template, and component library”. And that leads to my next post:

The problem with CMS frameworks.

Leveraging existing knowledge and techniques — ideal framework requirement #3

Too many framework developers decide they’re going to be too clever by half. As a result, writing plugins, extensions, modules, templates, models, views, controllers, classes, procedures, whatever you call them is always a unique experience.

My rant about ORM (and templating) tools was one part of this. Writing records to a database is not rocket science. But learning the way tools want you to do it sometimes is. I realize there is sometimes complexity that it is trying to hide, but don’t. That’s what I’m talking about with magic.

It’s okay to use an abstraction layer. It’s even okay to use an ORM if you really feel like it. But I should be able to quickly trace my code’s path and debug what’s happening. Even if (most like) it isn’t your (the framework designer’s) code, it’s mine. At least I won’t spend all day pointing my finger at you.

But the truth is, chances are, I’m going to have to work around your framework, or customize it, or optimize it, or put in some ugly hack at some point. If you’re too clever by half, I’m going to (incorrectly) assume your framework can’t handle it, and throw it out. The cdbaby story on comes to mind.

Writing records to a database, or alternately using a cache, marking the cache dirty when appropriate, and using either a file-based or in-memory (local or remote) cache isn’t rocket science either. But if I don’t know how you’re doing it, I can’t poke around and figure out that it was my stupid configuration and not your brilliant framework at fault.

In summary, if I look at (to continue my example) a persistence class, it should look like something I’m familiar with. I’m aware that there are more techniques and idioms than one man can be aware of, but it seems too many people go out of their way to create their own.

I understand the desire to “do it the way you’ve always wanted to” — that’s a huge part of the open source itch. I’m guilty of it myself. But so many people just have such bad style. Or maybe I just can’t recognise good style when I see it. You probably won’t when you look at my framework and the new way I code.

Rails created whole new idioms and even rewrote (by dynamic class overloading) some of Ruby’s semantics, but they could do that because there wasn’t really anyone using Ruby at the time, so the syntax, coding style, and language idioms were practically up for grabs, as far as the larger programming community was concerned.

People (including me) were tolerant of learning Rails idioms (including ActiveRecord) because we were learning a new language anyway. But while some things (like ActiveRecord) had pretty good style; others, like routes, had a smell from the start. It’s often dismissed by humble programmers as “just not getting it” — but lots of people “just didn’t get” EJBs for years before the switch was flipped and suddenly everyone admitted that it was just a bad design from the start.

Another part of leveraging existing knowledge and techniques is using existing tools. I deliberately left that out, because I don’t always think its best. If you use an existing crappy library, the flavor will spread through your code, but things like loggers, unit tests, etc. have such entrenched methods, that while your annotation-based AOP injected distributed transactional logger is just going to confuse people — oh wait, that sounds like the standard way of doing things in Javaland these days.

You might be nodding your head and thinking “design patterns” but that’s NOT what I’m talking about. Design patterns, for the most part are something people talk about who want to sound smarter than everyone else. If only people who think they’re smarter than everyone else are going to work on your framework, fine — sprinkle some decorators and anti-singletons, and whatnot around and be sure to use those big words in your documentation. But design patterns are really things like arches and dormer windows, and I don’t think that has anything to do with web frameworks, and come to think of it, I can’t think of anything that arches and dormer windows have in common, except they’re parts of buildings, and neither one of them is really a pattern.