How aFramework Works
Published Saturday 10th of April 2010
aFramework is my home made PHP web dev framework that I run almost all my projects on.
Today I thought I'd exaplain how aFramework goes from a requested URL to a rendered page.
The Routing
Let's take the URL http://andreaslagerkvist.com/jquery/image-zoom/ as an example.
First of all aFramework looks at the actual domain name, in this case andreaslagerkvist.com, and from there determines which sites should be run.
See all aFramework sites go through the same entry point. Actually that isn't required but it's how I've set it up.
I've set up eandreaslagerkvist.com to point to 'AndreasLagerkvist aBlog aCMS aDynAdmin aFramework'. So those are the sites that will make up our page.
Next aFramework takes the actual request, /jquery/image-zoom/, and tries to match it with a defined route.
All sites in aFramework can define routes that point to specific page types. A route is nothing more than the route-definition followed by the name of the page, like this:
'/jquery/:plugin_name/' => 'JqueryPluginPage'
If aFramework can't fint a matching route it immediately calls the FourOFour class. If it can find a valid route it loads the requested page.
The XML Controllers
So, from http://andreaslagerkvist.com/jquery/image-zoom/ aFramework knows it should run the AndreasLagerkvist-site's JqueryPluginPage-page. It will set a route-param called $plugin_name with a value of "image-zoom" as well (because we defined a variable in the route (/:plugin_name/)).
Now aFramework looks for an XML controller with the same name as the one the route was pointing to. In this case JqueryPluginPage. If it for some reason can't find one it will die(), letting you know the file is missing. You shouldn't have routes pointing to unexisting controllers.
When aFramework finds the requested controller it loops through all the nodes in it. Each node represents a module. Here's what a controller might look like:
<?xml version="1.0" encoding="UTF-8"
<Base>
<Wrapper name="wrapper">
<Header/>
<Navigation/>
<Wrapper name="primary-content">
<IntroText/>
<Page/>
</Wrapper>
<Wrapper name="secondary-content">
<StyleSwitcher/>
<RandomLinks/>
<RecentComments/>
</Wrapper>
<Footer/>
</Wrapper>
</Base>
The Modules
Like I said, each node in the XML controller represents a module. A module in aFramework is basically just a part of the page like the header or footer or sidebar.
<Wrapper>-nodes are actually not modules, instead aFramework turns them into div-elements. The name-attribute is used for the div's id.
You can make modules as large or as small as you want, but I like to split the code up quite a lot so that it can easily be moved around or deleted. It also makes bug tracking easier.
Every module consists of at least a template (view) or a PHP class (controller). aFramework first runs all the modules in the XML-controller (executes the run()-method of the module's PHP class) and then fetches their templates.
This way modules can override other modules. You can for example tell the base-module to load a different style from the recent-articles module because no HTML is output untill all the modules have run.
When all the modules have been run and all templates have been fetched aFramework echo:s the page.
Finally
And there you have it, from URL to HTML.
Try out the demo to see aFramework in action or head over to the bugtracker to find out what's in store for aFramework. Want to try it out locally? Go to the official site and download the zip.
/ AL
- Tags
- Comments
- No comments
Bookmark this Article