I’m sure you had thought that the first part was the last part, but you are wrong :). After reading the first part, I didn’t thought again and gave up on my framework project. And you are right there is no commit, yet :) But things are getting clearer with each passing week (yeah not based on days but weeks because I don’t really have a lot of time to spare for this). So let’s go on with the second part.
In my previous post, I have described why I wanted to write my own framework. Now I will talk about how I decided to keep going on about it. I have used a very basic tactic: I wrote down what I expected from my own framework.
I used pen and paper for it. I’m sure many of you like to write on digital environments. Honestly, I like that too, however I’m not really comfortable with it. It always easier to write or draw something on a paper (or a white board). Especially drawing is easier. And that’s mostly what I did.
I have written some pseudo codes, and draw (wrote) many outputs. I tried to gather my requirements from the way I wanted to write a software, from the final output of the code. And I wanted that my framework to be a median for this. From the things I have wrote, I noticed that what I really wanted to do was a declaration based development. I wanted to declare a class as a controller, map it to a URL (also by declaration) and I wanted to things automatically done. It was pretty what Spring or some other Java framework do right now. But I didn’t want all the hassle of compiling and deploying, etc. I wanted that the framework automatically parses all the changes, and wanted to keep developing software same as PHP (save and refresh :).
As I wanted a declarative development, of course, I had to be able to create my own declarations. And these new declarations should have been available to the whole project. (And if these declarations were shared easily between the projects, all the better).
I did not want to limit myself with classes only. I wanted to use functions as well, because I don’t really believe that OOP is awesome and functional programming sucks. I wanted to route a request to a specific function with a single declaration. Or some other functionality I might require.
With the above requirement I remarked that I really wanted this framework to be really simple! Easy to learn, easy to customize. Scalability or performance was not the focus of my framework but simplicity. They were all secondary objectives to be achieved during implementation and I didn’t really care if there was a limit for them.
Next, I wanted bootstrapping, routing and other default behavior of my framework to be flexible enough. But not the way it works like in ZF. I didn’t want to use a class and lots of methods for this. Again I wanted to keep this framework as simple as possible.
So far so good. I have written down all these requirements, again on the paper. Again I noticed that the main purpose of the framework was simplicity and to achieve this simplicity I had some simpler(!) requirements. And I was done.
What I started to do next might surprise you: I didn’t started to write down code. What I did, was to search if there was already such a framework or not.
I had decided to write my own framework, however the reasons were not very clear. I have written them, I have converted them to requirements. I didn’t think of any implementation detail. That was not the case anyway! I wanted to find out what I wanted to achieve. Perhaps, someone else had already required things I required too, and had a solution for them! What I did next, was this: I started to search for declarative based PHP frameworks that was simple. I will discuss this in the next part.
Please hear my plea, don’t start writing code first! That’s why you will give up writing your own framework. You don’t know what you really need, you just write code for the sake of writing it. Requirements are the most important thing for a software. You have to write them and decide what you will do from them. And of course, don’t forget design too!
See you next time.