What is the best method of understanding how and why a framework was written the way it was?
Develop a feature for it, or fix a bug. If you use the framework for developing a real-world solution, you can make a list of shortcomings to address or features to add that would make your task easier.
Fixing a bug will really help you understand the code, because most of the time you are given a piece of example code that recreates it, which you can then trace down into the bowels of hell to find where things go wrong.
All it takes is persistence, really.
Take a very simple component and analyze the code. For example, look at some of the components of the Zend Framework (something utterly simple like Zend_Version
or, to step up a bit but still keep it simple, Zend_Debug
). Pick them apart and see what makes them tick. Then, try to write your own simple component.
You are on the right track. Just remember that Rome wasn't built in one day. Every house is built over a longer period, brick by brick.
By using a framework, you will discover some of it'S shortcommings and be able to find some functionality that is missing or needs improvement.
Start there, develop the improvement and submit it to the frameworks community for peer review. Even if they decide not to include your work into the framework, you will receive very valuable feedback on your work.
Don't stop there, use what you learned in your first attempt for a second one (and a third, fourth, fifth...) That way you will learn to understand what others expect from the framework (which might differ very much from your own expectation), and slowly understand the inner workings of hte framework itself.
Conclusion: Be patient and persevere. Understanding will follow. (Sounds esoteric, I know. But it may work!)
I know the world needs another like it needs a hole in the head, but writing your own framework is a great way of learning a language. I wrote a fairly complete one in PHP in under a fortnight and learned a hell of a lot about PHP and Web development in the process.
The only reason I haven't released it is because I was finally not happy with the way it managed session state, but that was a good learning experience too!
I think the way to begin framework design is to write down about 5 basic aims for it. For mine, these were:
- aimed at producing simple Web apps with a dozen or so forms
- aimed at people with a good knowledge of SQL
- no procedural code PHP or otherwise (except for that in SQL SPs)
- no HTML/javascript/CSS programming needed
- application described in XML
- work on a vanilla PHP/Apache stack
- no state maintenance on server
That was enough to get me started.
The other suggestion I can make is to try to build an app using the framewark at the same time as you build the framework itself. This will quickly reveal problems and suggest ideas for new directions abd features.
There are a number of things that most frameworks include, although the definition is fuzzy.
- Provide a basic bootstrapper (manage settings, setup environment, check for compatability issues between PHP versions, etc.)
- URL Routing - How to define rules for which URLs point to which pages.
- Manage plug-ins, libraries, modules, etc.
- Database ORM - Manipulate objects instead of writing SQL queries (simplified)
- Templating - Usually involves creating a mini-language for template logic (loops, conditionals) to avoid having PHP code in the template itself.
Beyond this, most frameworks also include a slew of libraries from simple e-mailing to advanced web service API's.
I would recommend two frameworks to look at:
-
I recommend this because it's a "batteries included" framework that works out of the box. It also has a great community, lots of 3rd party libraries. CI has a bit of trickery to get the framework to play nice with both PHP4 and PHP5, which is also good to know (because, for some reason, a lot of people still use PHP5). You should also take a look at KohanaPHP, which is a branch of CodeIgniter that has been rewritten as a strict PHP5 framework.
-
Zend is a module-based framework. Instead of dropping everything in a directory and churning out pages, you pick the parts you need and glue them together yourself. Since Zend is made by the folks behind the engine behind PHP (confused yet?) it uses "the latest and greatest" of PHP5 - everything is Objected-Oriented and it uses type hinting. Very clean code, if a bit verbose.
I think the essential stuff is the bootstrapper (the "glue" for the framework), as well as how each framework implements a system to support user-made libraries and plug-ins. The rest you can find as stand-alone applications elsewhere.
After making many websites 'from scratch' I found myself reusing the same scripts over and over, and I found some things tremendously tedious because I never bothered to abstract them away before for re-usability. So, if you have any experience making websites, you should have a pretty good feel for what your framework should include. If not, I would probably start by thinking of an MVC file structure, get your framework to first work with views, then controllers, then models. Then make sure each of those is easily extendable because no matter how hard you try, there will always be things missing... and then just start slapping on utilities as you need them (form helpers, model helpers, etc.). In other words, come up with a project for which you would like to use the framework, and build the framework and website concurrently.
you should really try to understand, on a high level, the life cycle of a request. here's a good example a what happens from request to response in the Zend Framework, http://framework.zend.com/manual/en/zend.controller.basics.html