My research into forum design
 

With all this talk of forums and community projects, I've found myself considering the best way to go about designing an extensible web-based forum system. It occurs to me that it may be a good idea for me to document this process. Someone else on these forums may make suggestions I hadn't thought of, and perhaps some people may find my approach to the development process to be of some interest. I also find that writing sometimes helps me to clarify my thoughts.

Research

The first step was to decide on a choice of programming language, as this would affect my search for useful tools and libraries. This choice is not set in stone, but it helps to make a sensible choice to save wasting one's time. I chose PHP, primarily for its ubiquitous nature and ease of use. A PHP based forum would be far easier to install than one coded in Python or Ruby, and developers may find PHP's realtively basic syntax easier to get to grips with.

Next came the hunt for suitable tools to make my life easier. I design web applications by trade, and I've found frameworks like Ruby on Rails to be valuable time-savers. Fortunately, PHP has some Rails-clones, and whilst they are nowhere near as advanced, they will save me from writing a lot of redundant code. The main web frameworks I found were: Symfony, CakePHP and Code Igniter. They take a similar approach to Ruby on Rails, and unfortunately for me, all suffer from the same flaw.

Problems with modularity

Let me clarify. In Rails, the web application is split up into a number of task-orientated directory. You have a directory called "models" where the database integration takes place, a directory called "controllers" which contains the internal logic, and so forth. All of the PHP frameworks take a similarly structured approach.

That's fine. It's very good practise to divide your code into discrete segments. The problem is that the way it is divided up does not lend itself to a modular approach. Ideally, one would want a directory for each module, keeping the code for each separate. Systems like Rails aren't designed for that purpose; often, there is only one folder for each task. One of the problems with many of these frameworks is that you can only have one "views" folder, meaning that your module's templates have to be mixed together in one directory. Not very modular!

Finding a modular solution

Two choices presented themselves. I could forget about the idea of using such a framework; or attempt to alter an existing framework to do what I wanted. The latter seemed more attractive, as it meant less work, but I wouldn't know for sure until I evaluated how easy the systems would be to change.

I didn't have time to go through the code of all three frameworks, so I made a choice and chose Code Igniter. It's the most lightweight of the three, and looked the most intuitive to use. Programmers unfamiliar with web frameworks would find it easier to understand then more complex solutions, and there would hopefully be less for me to do to get it to a modular state.

Examining the code

I took a look at the index script for Code Igniter, and my eye fell upon this:
This was both good and bad news. The application folder is where a developer puts their custom code. Having a variable like this is good, because the application folder can be customized, and bad, because it limits the customization to just one folder. For a modular system, I'd need the ability to divide up the application folder into modules.

I looked through the file further and noticed that $application_folder was tied to the APPPATH constant. I grepped the Code Igniter directory structure for this constant, and came up with 44 matches:
Fortunately, APPPATH isn't used often. More often than I would have liked, but not so often as to prove impractical to get around. Most of the files APPPATH resides in probably don't need altering. For instance, one probably wouldn't want each module to have its own error pages, so there's probably no need to alter Exceptions.php. Loader.php, on the other hand, looks like exactly the sort of thing I'd want to override...


If you've read this far...

That's where I'm up to as of writing. Unfortunately, my post has expanded into something far larger than I had anticipated, an oversight for which I apologise for. It all seemed so much more brief and straightforward in my head, yet when it comes down to writing it down, it all seems so much more lengthy. :o

If you've read this far, then I hope you found at least some of my post somewhat interesting.

Look interesting. But so far I can see, you just choose the language to develop a forum software and tools that could be used in the development. This is fine, as if all decided to devlop in PhP. However the most important task is requirements Engineering. what kind of features, database design, if you are gone a use database etc. For that I suggest that all people should send a list of features, or some body send all the basic features of a forum software and other people give suggestions on them. This way features will add slowly.

I think a much more useful kind of modularity would be along the lines of what has been achieved with Expression Engine. EE uses add-on modules for even some of the most basic features, making it extremely extensible. I think this sort of modularity is much more useful and practical than dividing your code via the MVC paradigm you describe, although the two could certainly be combined.