revjim.net

inklog: it’s what you’ve always wanted

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.