What is this technique? It comes down to only a handful of things. These are:
So how do these areas speed up development so much? Easy! They allow for a very clear separation of user interface and business logic. Through using a combination of View, Action, Partial and PartialLoop helpers, we can make a “widget” that we can drop into any view template in our application.
This widget will receive its data via a request to an action of a module/controller somewhere in our application, which for the sake of our example will be returned in JSON format. If it receives valid data, then it will render the output to our template specifications. If not, we handle this gracefully with a suitable user message.
The controller action that it calls will use the ContextSwitch helper to return simple data output. By default, it will return JSON, but this can quickly be updated to provide other formats, such as XML, CSV and TXT amongst others.
This controller action discretely encapsulated the data management requirements we need, avoiding the need to instantiate model classes throughout. Now, there is one spot to update if we need to improve performance, fix bugs, change returned fields and so on. Have a look at the included code to get a hands on understanding.
This example hasn’t taken in to account security or performance considerations; that’s the topic for another post. So next time have a think about taking the path of least resistance, or one of less with Zend Framework and try this technique. Already do it better? I’d love to learn more from you.