Saturday, December 29, 2012

Writing a Web Framework

I've been working on my own web framework for PHP, which will ultimately allow me to write websites on top of it faster than I could otherwise.

For those who don't know what a framework is, it's a collection of tools and processes that act as a base for something to be built on top of. It handles a lot of the common low-level functions that need to be taken care of, but don't need to be rewritten for every program that you write.

It may--and often does--provide an API (Application Programming Interface) that your code can link into or call to provide extra functionality. One example would be a database interface, where the API would handle connecting to the database, any queries going to it, and returning the data in a usable format.

However, the main purpose of a framework is to handle a lot of things that you would normally have to do yourself, so you don't have to think of them every time. There are a lot of different types, but since I'm working on a web framework, that's what I'll be discussing here.

Just a small list of things that a framework would have to handle:
  • Figuring out what exactly is being requested from the server, determining what code is needed to provide it, and executing that code
  • Having a master template, and inserting specific elements where needed
  • Making sure all of your code, configuration, etc. is loaded properly (particularly important for interpreted languages like PHP)
  • Separating business logic from display logic
  • Handling data storage; database, cache, files, etc.

So, now that I've explained some of what a framework does, I should say something about what it is.

It is hard.

it is complicated.

It is... a good learning experience.

The last point is the main reason I'm doing my own, rather than just using an existing third-party solution: I want to learn what goes into a framework, all the things that happen behind the hood that I've taken for granted, or have hacked together on a very ad-hoc basis.

I'm following a Model-View-Controller (MVC) pattern for it, and as of this writing, the only parts that I have functioning are:
  • Configuration handler
  • PHP Class autoloader (I will explain this in later posts)
  • Parsing a URL to determine what controller/method to call, and pulling data from it
  • Loading the controller & calling the method, passing in the data from the URL
I have a number of other half-done features, but right now it essentially just loads the configuration, a controller, and that one controller dumps out the URL arguments.

I was looking for something to write about, and this seems like something worth covering. I find it interesting trying to figure out how everything goes together, the best ways to do things, and all the small things that you have to think of while putting something like this together.

With this in mind, I will be spending the next while detailing some of the major parts of what I've done, challenges I face, and anything else that seems noteworthy as I go along.

No comments:

Post a Comment