Zend Framework

You manually rendered your views by creating a view object,assigning variables,and calling a render() method. The

Zend Framework has a default component called the view renderer,which handles two of these steps for

you:automatically creating a view instance and rendering a view script. The view instance is stored in the controller

instance as $this->view.

The request object encapsulates all the heep data  you could ever want to get your hands on, including all GET,POST

and cookie data. It also provides information parsed from the request uri,such as the controller and action names as

well as a special type of data called parameters,which can be set from the url to make your site more search engine-

friendly than using query variables. Complementing the request object,the respones object provides an encapsulated

way to work with the output stream. Action helpers are resuable classes that add functionality to the controller-

typically,functionality that would not be considered program logic.

The redirector helper does what its name implies:it allows you to redirect the user to a new page. The goto() method

performs the redirection and allows you to redirect to a specific action. The api provided is more desirable than using

headers directly,as there are several factors that can affect a Zend Framework application's url layout down the road.

The FlashMessenger helper is designed to store messages from one request to the next. It allows you to add a

message to be displayed on the next pagem,and it will handle all aspects of the session,including removing the

message from the session after it has been displayed.

View helpers follow the same logic as action helpers,allowing you to create components that are resuable for your

views. Many of the built-in view helpers assist with creating and binding forms to your views. The forms created with

helpers can be slightly wordier than normal. However,they do useful things like output escaping and they will make

creating select drop down lists from an array easier.

Accepting user input in a Zend Framework applications consists of two parts: filtering,which involves the modification

of data,to trim whitespace from the ends of strings or to strip html tags; validation,which occurs after filtering and

ensures that the data is reasonable. Both of these actions can be achieved separately with the Zend_Filter and

Zend_Validate classes.However, they are more commonly used together through the Zend_Filter_Input class,which

is designed to filter arrays of information,such as an entire form or set of url paramters. To use Zend_Filter_Input,you

need to first define two associative arrays: one for your filters and one for your validators.The keys in these arrays

refer to the fields you wish to validate,whereas the values define the rules to apply.

By default,the framework looks for a controller called ErrorController whenever a problem is encountered,instead of

throwing exceptions directly. It also sets a request parameter called error_handler with the request object.This

parameter contains details about the error condition. Front controller is fairly rigid in the url format that controls routing.

By using the rewrite router,you can add routes to the defaults or even override routes completely. The framework has

a number of events that are fired in a class known as the PluginBroker,technically

Zend_Controller_Plugin_Broker,which is a basic registration and notification class. These events allow you an

opportunity to interact and disrupt the dispatching process. Typically, this disruption will be in the form of changing

values in Zend_Request that will have effects down the road. Writing your own plug-ins is fairly simple.First ,all plug-

ins must subclass Zend_Controller_Plugin_Abstract and may implement any of the PluginBroker methods. Zend_Acl

is a powerful but decidedly confusing component that allows you to define the actions that a suer is authorized to take

on your web site. While Zend_Acl can be used imdepently of plug-ins and helpers,it is far more powerful as a

complete solution. It is a robust access system consisting of an inherited role assignment with both resource and

permission -level controls.

As with resources,creating a role is also very simple. All roles must implement Zend_Acl_Role_Interface. This

interface consists of a single method,getRoleId(),Addtionally,Zend_Acl_Role is provided by Zend_Acl as a basic role

implementation.

Zend_Auth is concerned only with authentication and not with authorization. Authentication is loosely defined as

determining whether an entityt actually is what it purprots to be based on some set of credentials. A Zend_Auth

adapter is used to authenticate against a particular type of authentication service such as ldap,rdbms or file -based

storage. Different adapters are likely to have vastly different options and behaviors,but some basic things are

common among authentication adapters. Each Zend_Auth adapter class implements Zend_Auth_Adapter_Interface.

This interface defines one method,authenticate(),that an adapter class must implement for performing an

authentication query.Each adapterclass must be prepared prior to calling authenticate(). Such adapter preparation

includes setting up credentials and defining values for adapter-specific configuration options,such as database

connection settings for a database table adapater.

Zend_Auth_Adapter_DbTable provides the ablity to authenticate against credentials stored in a database table. Zend

Framework includes serveral action helpers by default: AutoComplete for automating response for ajax

autocompletion;ContextSwitch  and AjaxContext for serving alternate response formats for your actions; a

FlashMessenger for handling session flash messages;Json foe encoding and send json response; a Redirector ,to

provide different implementation for redirecting to internal and external pages from your application; and a

ViewRenderer to automate the process of setting up the view object in your controllers and rendering views. 

The ViewRenderer helper is designed to satisfy the following goals: eliminate the need to instantiate view object

within controllers,view object will be automatically registered with the controller; automatically set view

script,helper,and filter paths based on the current module,and automatically associate the current module name as a

class prefix for helper and filter classes; create a globally available view object for all dispatched controllers and

actions. The front controller will pass any caught exceptions to the reponse object,allowing the developer to gracefullt

handle exception. Zend_Controller_Front and Zend_Controller_Route_Route_Module were each using methods of

the dispatcher that were not in the dispatcher interface. 

Zend_Db_Profiler can be enabled to allow profiling of queries. Profiles include the queries processed by the adapter

as well as elapsed time to run the queries,allowing inspection of the queries that have been performed without

needing to add extra debugging code to classed. The Zend_Db_Table class is an object-oriented interface to

database tables. It provides methods for many common operations on tables. By default, method of the table class

retrun a Rowset in instance of the concrete class Zend_Db_Table_Rowset and Rowsets contain a collection of

instance of the concrete class Zend_Db_Table_Row. You can specify row and rowset classes using the table

constructor's options array,in keys rowClass and rowsetClass respectively.

You can specify the database table name independently from the class name by declaring the table name with the

$_name class property in each of your table classes.  Zend_Db_Table_Abstract performs no infkection to map the

class name to the table name. If you omit the declaration of $_name in your table class,the class maps to a dtabase

table that matches the spelling tof the class name exactly. 

Rendering a form in a view script is as simple as <?= $this->form ?>. Under the hood, Zend_Form uses decorators to

perform rendering. These decorators can replace content,append  content,or precond content,and have full

introspection to the element passed to them. Zend_Form_Element tries to solve this issue through the use of

decorators. Decorators are simply classes that have access to the element and a method for rendering content. The

file form element provides a mechanism for supplying file upload fields to your form. It utilizes Zend_File_Transfer

internally to provide this functionality,and the FormFile view helper to display the form element.

By default, it uses the http transfer adapter which introspects the $_FILES array and allows yopu to attach validators

and filters. Validators and filters attached to the form element will be attached to the transfer adapter.

The Zend_Loader methods are best used if the filename you need to load is variable.Zend_URI is a component that

aids in manipulating and validating uniform resource identifiers. Zend_Uri exists primarily to service other components

such as Zend_Http_Client but is also useful as a standalone utility.The Zend-Uri class provides a factory that returns a

subclass of itself which specializes in each scheme.The subclass will be named Zend_Uri_<scheme>. If your

application requires even greater flexibility with which it reports validation failures,you can access properties by the

same name as the message token supported by a given validation class. If it is inconvenient to load a given validation

class and create an instance of the validator,you can use the static method Zend-Validate::is() as an alternative

invocation style. The first atgument of this method is a data input value ,that you would pass to the isValid() method.

The second argument ios a string,which corresponds to the basename of the validation class,reative to the

Zend_Validate namespace. Zeend_Validate supplies a set of commonly needed validators,but inevitably,developers

will wish to write custom validatios for their particular needs. Zend_Validate_Interface defines three methods, isValid

(),getMessage() and getErrors(),that may be implemented by user classes in order to create custom validation

objects. An object that implements Zend_Validate_Interface interface may be added to a validator chain with

Zend_Validate::addValidator().

Zend_View is a class for working with the view portion of the model-view-controller pattern. That is, it exists to help

keep the view script separate from the model and controller script. It provides a system of helpers,output filters and

variable escaping. Zend_View is a template system agnostic; Essectially, using Zend-View happens in two major

steps:1.your controller script creates an instance of Zend_View and assigns variables to that instance.2. The

controller tells the Zend_View to render a particular view,thereby handing control over the view script,which generates

the view output. By default,Zend_View expects your view script to be relative to your calling script. Zend_View comes

with an initial set of helper classes,most of which relate to form element generation and perfom the appropriate output

escaping automatically. The action view helper enables view script to dispatch a given controller action.