“Ugh, is this over yet? I should be watching ‘ALF’ reruns!” My disdain for the concert was apparent. As a developer who spends his time reading code, watches a bit of TIVO-recorded shows,and is just not a classical music type of guy, watching a concert was just not me. However, as the concert continued, I watched in amazement as the composer raised his hands up and down, swayed side to side, and brought order to the sounds that these complicated instruments made to create music.
Like the orchestra, Zend Framework contains its own classical music wizard: the Zend_Controller, which is ready to bring order to all the steps and components the Framework is required to call to make an application run properly. The Zend_Controller brings order and is the figurative glue that binds together all the steps and libraries to make your application worth the trouble to build.
This chapter begins by taking a look at the model-view-controller (MVC) pattern. You want to set the foundation for Zend Framework and know why it promotes the use of the MVC pattern. You’ll look at what the MVC pattern is; why it was introduced into the web industry; and how it has become a leader in creating fast, loosely coupled applications. You will then work with the Zend_Controller component, learn what controllers are, implement best practices when creating controllers, and add functionality to them by extending the Zend_Controller_Action class. You’ll also see how Zend Framework processes a URL so it maps to a controller action pair and learn how to manipulate this mapping feature using the Zend_Controller_Router_Route class.
With an understanding of how a controller is created and accessed, you’ll learn how to use the Zend_Controller_Request_Http class to retrieve HTTP data, such as data from a form submission, and how Zend Framework handles errors using Zend_Exception.
Model-View-Controller Pattern
The MVC pattern is a computer science pattern widely used in today’s web industry, but that was not always the case. The MVC pattern, introduced in 1979 by Trygve Reenskaug, had a following in the software engineering field, specifically in the SmallTalk communities at the time. Software engineers adopted the pattern because it offered an efficient method of creating loosely coupled applications and maintaining software applications. With the MVC pattern’s success in software engineering, the web industry took the figurative plunge into the MVC world.
Why Use MVC?
The MVC pattern made a lot of positive noise in the software engineering field. Why, after so many years, should you continue to use and build software under this pattern? Because the MVC pattern is the logical step when creating web applications, as you’ll see.
As a web developer for 10 years, I’ve seen the process of developing and launching a web application change. In the past, a web developer had to be versed in both the front end and back end. Now, however, there is a systematic way to build web applications. In most cases, the back-end developer is not the front-end developer or the person with all the knowledge concerning the business rules/logic the product is required to use. In most cases, these positions are held by different individuals in the company, and the layout and the back-end code usually must be simultaneously developed to keep up with deadlines and milestones the team has set.
The two positions, front-end developer and back-end developer, are easily represented in the MVC pattern. While the front-end developer works on the view, where the display markup resides, the back-end developer can focus on creating the controller and the models that contain the logic that powers the application. This separation of power decreases the overall time it takes to create the application.
The MVC pattern also solves the issue of how to reuse major features. By separating features into distinct and loosely coupled modules, you can easily plug these features into other applications without having to copy the bulk of the application that initially implemented it. Before MVC, this was a time-consuming task. If you required only the design of a login form, you had to take the time to remove all the additional code that might have retrieved any incoming data and checked whether the submitted login information was valid. If you wanted to use only the authentication features, you had to remove the design markup.
Using the MVC pattern the functionality built for one application can be easily reused. The login and authentication feature has three components: the view, a controller, and a model. If you want to reuse the look and authentication logic, you can easily copy just the model and the view files, and disregard the controller file.
What Is the MVC Pattern?
The MVC pattern breaks a project into three manageable modules to satisfy the separate functions in a development process and achieve the loosely coupled design mentioned previously.
Figure demonstrates each distinct piece in the MVC pattern: a controller, a view, and a model. Without all three of these components, the MVC pattern could not help the web developer, and your application would not be considered a MVC application. I’ll briefly go over the separate components before you dive into the code.
The controller contains code to handle all the allowed user events and coordinates the view and models—culminating with a response to the user. In Zend Framework, each user event is represented by a request, each request is handed to an action that knows how to deal with it, and each controller can have an infinite number of actions. If you constructed a controller that allowed the user to retrieve all accounts in the system, retrieve a specific account, and add a new account, code to handle these events would be contained in corresponding actions inside a controller that handles account functionality.
A model contains domain-specific instructions. Because the controller directs the functionality of specific sections/pages in your application, you need a place to keep all the business logic. The model is the place where you’ll find how to retrieve different types of data—such as information stored in a database, the contents of XML files, or the results of a web service call—or simply return specific values for specific inputs. In the account example, when using an action to log into a system, you can implement a model containing all the logic to authenticate a user that the controller would instantiate and use.
The view is the user interface of the controller. It is the public face of the user event’s response. Because you’re building web applications, the view would contain HTML, cascading style sheets (CSS), JavaScript, forms, and the cool images you have learned to love.
MVC Life Cycle
You now know what components the MVC pattern contains, so take a look at the life cycle of a user’s request in a MVC application.
This can be a bit confusing, so I’ll break it up into manageable pieces. Start at the top of the figure: the black dot. The user arrives at a web page, which is the initial step of the MVC pattern: the user triggering an event. Events always occur from the request for a specific URL by a user or another application such as a web service.
Move down into the MVC pattern and enter the controller. The user’s event is translated into a request for a controller. This is where each piece of the MVC pattern begins to talk to the others. The controller determines whether it needs to load the model to format, transform, or process any information that the user has submitted or if the user simply wants to view a page. The model then returns any data it processed back to the controller. The controller finally specifies a design to render to the user by retrieving a view.
After the user is presented with the view (the XHTML side of the application), the user’s request drops out of the MVC session and waits for the next request. If the user requests another page, the entire process restarts until the user stops or leaves the application.
Now that you know what MVC is and how each piece of the MVC pattern is used, you get to play around with some of the MVC functionality within Zend Framework.
List Of Topics ){kind=icon}
Zend
Related Jobs