January 3rd, 2003:

Apparently my entry regarding my decision to create my own weblogging software has attracted enough readers to cause quiet a few people to notice my complaints about cafelog. Mike thinks that I have been unfair in my evaluation, and he’s right. I was a bit harsh.

To be completely honest, my first draft of that post included something along the lines of “One thing that can be said for b2 is this: It works and it has plenty of users.” Somehow, through all of the editing and screaming at the use of pointless database queries, global variables, and some of the most difficult logic I have ever tried to follow, that little statement got lost.

The truth of the matter is this. I had looked at the code once long ago and was immediately scared by the ugly URLs. However, after seeing more and more people starting to use it, I decided to give it another shot and see if I couldn’t modify it to suit my needs. It was then that I saw how horrible the code is (on which, Mike agrees with me, at least in part).

I stated somewhere towards the top of the post that the features that Ifelt were missing “might actually exist in cafelog already, and I was just so unwilling to read every line of code written in order to see that”.

Is the code inefficient? Yes. Could it use a rewrite? Yes. Does it break almost every rule that “good programmers” attempt to install into the minds of others? Yes.

Is it a total piece of shit not worth using by anyone? No. Not at all. Would I use it as it is now? No. If the author agreed with my vision, at least in part, of how it should be, would I be willing to help make it that way? Absolutely.

Actually, one of the nice things about cafelog is that it is written horribly. Bear with me on this one. While programmers like myself start convulsing when we have to wade through such code, less experienced programmers actually like it, because it is easier for them to work with. Because the “template functions” are in the global namespace, they work anywhere. Because the data returned by the database is in a global variable, you don’t have to use any tricks to get at it. It makes extending, enhancing, and modifying the code easier for newbies.

I still think it should be rewritten. However, examples and documentation should be provided to help unseasoned programmers get over the small learning curve that takes place when things like “classes”, “references”, and “function parameters” are used. When written cleanly and offered with examples, it can be made just as easy to modify as it is now.

I’d also like to thank Mike for being the first cafelog user to inform me that there is an easy hack for it that allows friendlier URLs and then actually find him using it.

I’m bored. So, I’m going to put my keyboard where my mouth is: I’m writing a PHP based weblogging application that doesn’t suck. Well, maybe it will suck, but it’ll suck less.

As much as I’d like to be able to contribute to an existing project, there just isn’t anything out there with enough usable code to make it worth my while. However, I’d still like to use existing components if at all possible. This means using existing templating engines, database abstraction layers, toolkits, caching mechanisms, etc.

I’m looking for comments, suggestions, and desires. I’m looking for examples of functionaity that you’ve seen in other weblog applications (or any application at all, really) that you like, or found easy to use. I’m looking for input from seasoned PHP programmers, programmers of other languages, new coders, and even those of you who don’t know anything about programming.

If you are a weblogger and you dislike anything about the software you currently use, now is your chance to speak up.

I’ve got about 95% of it worked out in my head. There’s one piece that isn’t quite right. I want it to be as extensible as possible, and therefore, don’t want to even limit the file names used, the extentions of those files, or the appearance of the URL line. Additionally, I’d like to allow the templating engine to be flexible so that if a PHP site already exists using another templating engine, that engine can be used throughout the site. I’m not entirely certain how the “Controller” should be built. As I see it, I have a few options.

I can combine the controller with the view (therefore forcing my templating engine to be used) and create custom tags that are placed in the document to retrieve information from the Model. This is very similar in use to MovableType, with its <MTEntries> tags and the like.

I can allow the user to predefine the available elements via an XML file. This would mean that, using an XML syntax of my design, a user would inform the weblog application of which elements should appear on each page. For instance, when designing the front page, a user might include the getRecentItems, getRecentComments, listCategories and listArchives elements. The parameters to each of these elements would be defined as attributes within the XML syntax.

I can allow the page elements to be defined by authoring small, simple PHP scripts that gather the data. This has the advantage of being very fast, and very easy for a PHP programmer to understand. This, however, has the disadvantage that, unless a user likes the default elements available on a page, they will have to edit some PHP in order to change that.

I can create a web interface that allows the definition of the elements for each page. This makes the system very easy to use, however, it is possible that a user might desire to do something that I don’t initally consider. In this case, changes will have to be made at the application level in order to allow that user to accomplish what he/she desires.

Of course a combination of any/all of these methods could also be considered appropriate.

I’m all ears.