Introduction
Welcome to the second part of our voyage into the world of MVC. Our mission: To build an MVC framework that is:
- Simple
- Extensible
- Lightweight
- Versatile
- Fast-loading
- Self Templating
- Reusable
Note that all the code in this article is downloadable HERE, although I recommend actually coding this yourself if you are actually trying to learn anything from it.
Unlike the previous part, I am not simply giving you the part of the framework that we discuss, but a much more complete version. You will need a MySQL database to run it on, and you will have to setup the connection in application/db.ini.php. My example should guide you. You should not have to do much else than create the database and connect to it. The application will build its own tables. How it does that is something we will get to in due course. Please note this is an open source application, but a mention of my name or a link back to this article would be greatly appreciated should you decide to try use it. The code in that framework represents many, many hours of coding and architecture.
If you are interested in part one, it can be found HERE.
Bootstrapping
As promised in the previous section, we are going to take a closer look at Bootstrapping. Bootstrapping refers to a self-sustaining process that continues without external help. The term is often attributed to Baron Munchausen, who, in a story called The Surprising Adventures of Baron Munchausen, pulled himself out of a swamp by his own bootstraps. What it means in coding terms is that the bootstrap file is actually what holds everything together. What you will notice is that the bootstrap is in the “application” directory, and that the application directory is actually outside our web root (public_html). This is extremely important for security reasons. With the actual framework outside of the web root, we remove any threat of the website’s logic data being accessed illegally. But, taking all of this out of the web root we have a slight trade off though: we need to channel the entire application through a single file, from where we can manage everything. And this is the bootstrap. So, we recall, what actually happens is that our website is first channelled through public_html/index.php, and then we re-route everything through the bootstrap.
Let us take a look at the document structure. In figure One (below) we can clearly see that the application and library directories are outside of the public_html directory, or web root.
Figure One
Below I will show the complete example of what the actual bootstrap file will look like in the next few editions. For those of you who are familiar with the heavier frameworks like Zend Framework, you will notice how light the bootstrap footprint actually is. What I have been trying to accomplish here is simplicity. Obviously there are always things that have to be setup, and this is where we do that.
Figure Two
The Registry
What you will notice in Figure Two (above) is that the first thing we do is instantiate a class called Registry. Then we proceed to pass just about everything we create after that through this registry. The idea is that the registry will be a “data source” of sorts–sort of like the DNA is your blood: every DNA molecule contains all the information required to build your body from head to toe. The Registry is basically the same thing. Everything is in the registry, and the registry is in everything. What this actually does is remove the need to use those ugly and somewhat shaky “global” calls inside classes. If we need something, like a database connection, you can rest assured, it is in the Registry. But how, exactly, do we create a class that can be used in such a manner? Well, luckily for me, PHP has magic GETTER and SETTER methods. let’s look at Figure Three.
Figure Two
As you can see, the Registry Class actually extends the abstract registry class. Abstraction is perhaps something for a different topic all together. However, what is important are the __get() and __set() functions. These are known as “magic” functions: they automatically assign and retrieve values passed into a class without having been told to do so. Thus, the __set() function actually takes all values being passed into the class and assigns them to a variable. The __get() function then grabs all those variables and makes them available to the class again.
Conclusion
At this point you have a more-or-less complete framework that only needs a little revision in order to be really tough and secure. As we continue we will look through each and every function and class in this application and explore exactly how it works.
I know that I promised to look at the gException class this week, but, alas, time forbids it and I do not want to merely gloss over this aspect of the system. So next time we will dedicate a lot of attention to exception classes.
Until next time,
Marc Steven Plotz
