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.
Let me describe said situation for you; The user has a list of items and they’ve chosen to delete one. Given such a volatile action, you want them to doubly opt-in and confirm that they want to do this.
The last thing you want your user to feel, after they’ve clicked the delete link, is “NO WAAAAAAIIIIT! I didn’t mean to do that”. So the user clicks &’delete&’ and is directed to a confirmation page (which is rendered with Zend Form). There are two buttons on the page; the first is “Delete Item”, the second “Cancel”.
If the user clicks either button, the form submits to itself, where the value of the button clicked is determined. If the user clicks “Delete Item”, then the deletion is carried out, deleting the item from the datasource. If the user clicks “Cancel” the user is returned to the list of items they were previously viewing, the item is not deleted and the user is provided a message, confirming the non-deletion.
So in the last installment of this series, I provided an introduction to Zend_Auth, Zend_Auth_Adapter_Interface and Zend_Auth_Result and how to implement Zend_Auth_Adapter_Interface to implement a basic test adapter that can be used as a mock object in your testing.
If you missed it, check it out now, then come back and we’ll continue on. If you’ve already read it, then let’s continue now.
As I indicated last time, whilst being a perfectly valid implementation, the Test adapter was rather basic and didn’t do very much. Like all good testing, you need flexibility and options. So in this installment, we’re going to build an adapter based around Zend_Config. This will lead quite nicely in to the last part in the series which uses the wonderful MongoDB as the underlying resource for the adapter.
Zend_Auth provides a very extensible workflow for creating new adapters to suit your authentication needs. In this post, I start you off with a simple Test/Mock adapter.
Do you want a scalable, high performance PHP application that logs everything in an intelligible manner; in a manner that you can use now, tomorrow and three weeks from now? It’s so possible! In a series of posts, I am going to show you how to put it together using Zend Framework, ZeroMQ and Hadoop.
Zend Auth, if you want to secure a Zend Framework app, along with Zend Acl, it’s essential. But do you know what it is? Do you know how to use it? Do you know how to extend it? Through this series I’m going to show you how to do all three.
phpMagazin recently did a good job of covering Zend_Translate; specifically what it is, how it works and four of the basic translation adapters; those being Array, CSV, Gettext and Ini. However, what they didn’t cover was what I think, is one of the best choices of adapters that Zend_Translate has; which is TMX.
This is a mini-post showing you how to get up and running with mongoDB and Zend Framework using a series of third-party libraries, including Shanty-Mongo library. To be honest, it’s rather trivial, but sometimes it can be frustrating trying to find a simple, concise, reference on how to do it, specific to just your needs.
After stating our 11 Reasons Why A PHP Framework is better than Raw PHP, here’s 11 Reasons Why A PHP Framework is better than Raw PHP
It, often, has a solid community of professionals developing and supporting it It’s, often, coded to an exacting, mature, coding standard It has a solid development history, reviewed by many eyes It has defined methods of doing repetitive things quickly and simply You’re not on your own and call fall back on people for support It’s, often, simple to link in with existing 3rd party libraries – quickly and easily You’re working within clear constraints and development concepts You can bring in developers already experienced with using and deploying it There are tried and true practices for deploying it There are tried and true practices for testing it Frameworks carry brand and industry recognition What do you think?