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
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.
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 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.
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.
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.
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 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 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)