The Zend Framework Bootstrap can be one of the key aspects of getting up and running quickly with the Zend Framework. Let’s make it easy.
The bootstrap in any web-based application is important to get right, however Zend Framework makes us put in extra effort to do it right. So in the Zend Framework Bootstrap series we’ve seen a concise, time saving approach for taking a lot of the pain (erm) effort away. But here we are at the end of the series. So like all good software projects, it’s time for a bit of a retrospective on the series. Let’s look over what was covered.
Part 1 - Getting Started
As you’ll remember, in the first part of the series we laid the foundation for the series by talking about what the bootstrap is and what it does, specifically in the context of the Zend Framework. We followed that up by creating a custom bootstrap class and class library directory structure. Following this we added its namespace to the application ini and modified the default application bootstrap so that it extends from it. At this point, any application will start to have instant access to the wealth of resources that we’re about to give it. We then rounded out the first part in the series by looking at one of the most important components - caching.
Part 2 - Factoring in Routing, Navigation and more…
Then, in the second part of the series, we built on the foundation laid in part one by creating plugin resources for the other most important components in web-based applications:
- The routing table
- Application navigation
- Datasource (database) connections
Part 3 - Placeholders and Resource Plugin classes
And finally in the third part of the series, we took a slightly different path from the previous approach and instead of creating bootstrap resource methods, we took the approach of creating resource plugins which made implementing placeholders and paginationjust a piece of cake. Why was this so? Because instead of the resource plugins, by using this approach, all the user needs to do is to add configuration options to the application.ini.
What are your thoughts?
So what did you think - yes you; you, sitting there at the keyboard, reading the iPhone on the train, reading the Android in the taxi? Did the work go far enough? Did it cover enough for it to be meaningful for you? How can you use this approach to bootstrapping in your next (or current) Zend Framework application?
Ok, we’ve established that with the Zend Framework, we need to do a bit more work than some of the other frameworks to get up to speed - but that’s not necessarily a bad thing - right?! But it can be a bit tedious and it’s something as professional developers, we want to automate away. So we’ve been addressing in this series how to do just that with a custom, extendable bootstrap class.
In the first part of the series we laid the foundation of our custom bootstrap class by creating a custom class directory structure, adding its namespace to the application ini and modifying the default application bootstrap so that it extends from it and had a look at the first component - caching.
Then, in the second part of the series, we built on the foundation laid in part one by creating plugin resources for the routing table, application navigation and the database connections - these being some of the most common tasks, usually, associated with a web-based application.
In this, the third and final part of the series, I’m going to finish up by looking at application placeholders and surprise, no not logging as originally promised, but pagination. As an added extra, we’re going to be using a key feature of Zend Application to make it a breeze.
In the first part of the series, you’ll remember that we laid the foundation of our custom bootstrap class by creating a custom class directory structure, adding its namespace to the application ini and creating our custom bootstrap file that our application bootstrap will extend from.
After we did that, we put in the first but arguably the most important plugin resource – caching and stored it in the application registry. In this post we’re going to be building on that work and adding in three new plugin resources: routing, navigation and databases.
When you’re creating a new project with the Zend Framework, unlike other frameworks, you need to do more legwork. This isn’t necessarily a bad thing, but it can sure slow you down when you’re trying to plough through a project.
I really enjoy using it, as it has a very well structured approach – and I like structure – it clearly lays out a file-system structure for modules, controllers, actions, forms, models and so on. It has good, but basic, tooling, allowing for modest project initialisation. But despite all this, it still requires a healthy investment on our part to get a proper foundation in place to use it productively.
In a recent project I encountered this situation and felt that I mustn’t be the only one to do so. As I plan to keep using Zend Framework I want to work around this situation and get as much productivity out of it as possible right from the get go. But how to do this?
Bootstrapping
Well the primary focus for me is bootstrapping. It provides the majority of the core services that every project needs, from routing, data source connections, authentication, authorisation, navigation, caching and so on. So it stands to reason that it’s a good place to start. So I want to cover what should go in to a good working bootstrap.
Recently I was asked how to rename a file with the Zend Framework that used a Zend Form and Zend File element. They key requirement was that it should not be a hack or a kludged solution. So I thought I’d write a quick post to provide a simple example on how it was achieved.
Join the discussion
comments powered by Disqus