I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

Zend_Glossary

11.23.2010
| 6169 views |
  • submit to reddit

When you're approaching a framework with a learning curve as steep as ZF, it's easy to be overhelmed by new terms and declare them buzzwords. Instead, they have often a very precise meaning.

I've creates this glossary to collect all the defined terms I could find, so that the PHP developer new to Zend Framework would have a place to come and lookup in the time of confusion.

Highly generic -and reused throughout the whole framework

Adapter

An adapter is the equivalent of an hardware driver, for a particular component. The Zend_Db component can work with different adapter, related to different dbms; Zend_Auth can work with different authentication mechanisms, such as http-based or backed by a database. Zend_Translate accepts gettext as an adapter, but also xml or csv-based ones.

Loader

The Zend_Loader component, and the term loader itself, addresses the class loading mechanism of the application. Sometimes the loading is done globally via autoload - like when you require to instance Zend_Form or Zend_Translate. In other case, a resolution mechanism involving a prefix is performed, in cases such as form elements, filters or validators. This layer of indirection allows you to insert your own classes in the loading process: custom view helpers and action helpers are an example of this hook.

Helper

Helper is a very generic term, but in Zend Framework assumes the meaning of a collaborator object which is usually never stubbed out. Helpers may be tested independently, but are not mocked during the testing process of their client code, due to the large contract the main class relies on and the difficulty of the injection into the core of the framework.

Action helpers are collaborators for controllers. For example, the Redirector action helper provides a mean to send HTTP Location headers for redirect's sake, while the Json one encodes the response variables in Json before printing them and exit.

View helpers are collaborators for view scripts instead. For example, the Url view helper generates an url conformant to the routes of the application from the controller and action names, and the Head* series of view helpers takes care of collecting metadata and printing <head> tags like <link> and <style>..

A broker is the point of access for a set of helpers. Action helpers have an independent broker, while the Zend_View object can be thought of as the broker for view helpers. The broker embeds the instantiation code, and it is viewed as a generic component in the under development Zend Framework 2.

Component names confusion

Locale and translate

Zend_Locale is a component that takes care of the translation between different user input formats (localization, or l10n for friends) and the one used by your domain model. For example, date formats like 23/11/2010 and 2010-11-23 can be matched with the help of Zend_Locale.

Zend_Translate instead is dedicated to the internazionalization (i18n) of an application: the translation of labels and messages into different languages. The two components are not overlapping.

Auth and acl

Also Zend_Auth and Zend_Acl are two complementar components. Zend_Auth takes care of the authentication of the current user, providing adapters against different back ends (relational tables, LDAP, etc.).

Zend_Acl takes a further step into this realm, prodiving control over the authorization of users. Once you know the identity of an user (via authentication) you can identify what actions he is allowed to perform via a rule mechanism, managed by Zend_Acl.

MVC

The model of an application is the part of it which is domain-specific, and thus by definition can't be provided by a generic framework. There is no Zend_Model: Zend Framework provides you with the tools to persist your model's data, like Zend_Db, but it does not prescribe any particular implementation for your model classes.

The controllers of an application are the main container of the application flow. The take a HTTP request as input (wrapped into an object) and act to provide a response accordingly. A controller is usually inferred from the current Url and called automatically by the framework.

The view object is used to render one or more .phtml scripts and creating a response, often in HTML. The view receives a set of data from the controller, that has assembled them by calling the model objects. The view object is also responsible for rendering a layout (Zend_Layout), which is Zend Framework's implementation of Two Step View. A full discussion of the pattern is out of place here, but you can learn more in the related Two Step View article.

Bootstrap

Zend_Application is the Facade object for an application built with Zend Framework 1.8 or superior. It is used during bootstrap and allows the selection of a particular configuration and application path.

A bootstrap object is used by Zend_Application as a container of bootstrap code. A resource is targeted by Zend_Application in the bootstrap too, but it is a reusable piece of functionality instead of a monolithic bootstrap class (you can have only one bootstrap, but as many resources as you want.) The related article will explain you how to use bootstrap and resources.

Forms

Filters

A filter is a chainable piece of code that takes a single variable as input and produce a function of it as output, without side effects. Many filters work on string, performing task such as trimming or lowring cases. The point here is that you can chain the filters together via configuration, for example trimming and filtering bad characters from a form field automatically. A filter by itself does not do very much: its power resides in its uniform interface, an interface that the procedural filter extension doesn't have.

Validators

Validators are stricter than filters: when the provided value does not satisfy them, they can reject it and raise an error, which will be shown along the related form field. Noth validators and filters can be used independently, and noy only in form fields. Errors you can repair, like additional spaces, are addressed by filters; errors that make you ask the user for help are addressed by validators.

Decorators

Decorators are instead a Zend_Form specific component. As the name suggests, they are chainable and handle the rendering of a form field or of the whole form itself. For instance, one decorator usually adds a <label> alongside the input, while another adds a <fieldset> or other markup. Again, the point is in chaining small pieces of functionality to achieve the result, in this case being it the display of forms and not their data validation.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Brian Reich replied on Tue, 2010/11/23 - 2:15pm

Excellent article.  I'd be all for seeing this go into the official Zend Framework Reference Guide.

Matthew Weier O... replied on Sun, 2010/11/28 - 10:57am

A few notes:
  • Zend_Translate actually has a dependency on Zend_Locale; the locale is used to determine what language is used for translations.
  • I recently realized that the "Decorators" in Zend_Form are actually a perfect example of the Visitor design pattern -- which may help developers trying to understand how they work. :)
Nice glossary!

Giorgio Sironi replied on Tue, 2010/11/30 - 3:42am in response to: Matthew Weier O'phinney

And which may help rename them from Decorator (a pattern's name) to the right Visitor terminology. :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.