A module offers an HTTP interface which can be used for web based interaction with eZ publish. While some modules offer an interface to kernel functionality, others are more or less independent of the kernel. The system comes with a collection of modules that cover the needs of typical everyday tasks. For example, the content module provides an interface that makes it possible to use a web browser to manage actual content. It is possible to extend the system by creating custom modules for special needs. Custom modules have to be programmed in PHP. The following table gives an overview of some of the most commonly used modules that come with eZ publish.
| Module | Description |
|---|---|
| The "Content" module provides an interface to the content engine in the eZ publish kernel. This module makes it possible to display, edit, search and translate the contents of objects, manage the node tree and so on. |
|
| The "User" module provides an interface to the user management system in the kernel. This module makes it possible to log users in and out of the system. In addition, it also provides functionality related to user registration, user activation, password changing, etc. |
|
| The "Role" module provides an interface to the access control system in the kernel. This module makes it possible to create, modify and delete roles and policies. In addition, it provides functionality for assigning roles to different users and user groups. |
Please refer to the "Modules" section of the reference chapter for a comprehensive list of all the built-in modules.
Every time eZ publish is accessed using a web browser, the client application indirectly interacts with one of the modules that are present in the system. The requested URL tells eZ publish about which module it should execute in order to process the request. In particular, the first part of the URL reveals the name of the module. This is usually the part that comes directly after "index.php" unless the URI access method is used. The following example shows a typical eZ publish URL:
http://www.example.com/index.php/content/edit/13/03
A quick glance at this URL reveals that the request is directed at the content module. Another typical example of an eZ publish URL could be something like this:
http://www.example.com/index.php/user/login
By looking at the URL, we can immediately tell that eZ publish will attempt to execute the user module when processing this request. Obviously, some additional information is also specified in the URLs. In the first example, the name of the module is followed by "/edit/13/03". In the second example, the name of module is followed by "/login". These additional strings control the behavior of the requested module and are explained below.
A module consists of a set views. A view can be thought of as an interface to a module. By using views, it is possible to reach various functions that a module provides. For example, among other things, the content module provides views for displaying, editing, searching and translating the contents of objects. The name of the view that should be accessed appears after the name of the module (separated by a slash) in the URL. In the first example above, eZ publish is instructed to access the "edit" view within the content module. In the second example, eZ publish is instructed to access the "login" view within the user module.
When a view is called, eZ publish starts up the program code that is associated with that view. Upon completion, the view returns a result to the module, which in turn returns it to the rest of the system. The result is put inside a template variable called $module_result.content which is available from the main template, the pagelayout. Please refer to the "Template generation" section of the "Templates" chapter for more information about this part of the system.
Some views support on one or more parameters. A view parameter makes it possible to pass information to the view itself and thus allows the view to be controlled from within the requested URL. The view parameters are appended after the name of the view in the URL. In the first example above, the following parameters are passed to the view: "13" and "03". These parameters will instruct the edit view of the content module to provide an interface for editing the third version of the thirteenth content object in the system. The URL given in the second example does not make use of any view parameters. The view mechanism supports two types of parameters:
The ordered parameters have to be separated by slashes and they must come after the name of the view. In addition, they have to be provided in the same order as it is specified in the module's definition. For example, if the view parameters in the first example get mixed up, eZ publish will attempt to edit the thirteenth version of object number three (instead of version number three of object number thirteen).
As the name suggests, the unordered parameters can be provided in an arbitrary order. If the view supports ordered parameters, the unordered parameters must come after the ordered parameters If the view doesn't support ordered parameters, the unordered parameters will come directly after the name of the view in the URL. The unordered parameters must be provided in pairs. A pair consists of the parameter's name and value separated by a slash. The following example shows an imaginary eZ publish URL with unordered parameters passed to the requested view:
http://www.example.com/index.php/video/dvd/button/play
The address in the example above tells eZ publish to run the imaginary "video" module and execute the "dvd" view. A variable called "button" will be created and made available for the view code. The value of the variable will be set to "play". It is up to the PHP code of the view to discover this variable and to carry out a necessary sequence of actions.
Some views make use of parameters that are submitted by the way of forms through the HTTP POST method. For example, the action view of the content module makes an extensive use of POST variables.
In order to be able to produce proper output, eZ publish must know which module it should run and which view that should be executed. In other words, every URL has to contain at least the name of an existing module and a view. If an incomplete or mistyped URL is provided, eZ publish will display an error page revealing what's wrong (missing/mistyped module or view). If the requested URL doesn't contain anything after "index.php" (except maybe a slash), the default module/view combination will be executed. The default module/view combination can be configured using the "IndexPage" setting under "[SiteSettings]" in an override for "site.ini". The default setting is "/content/view/full/2". It instructs eZ publish to show a full view of node 2, the content top level node. In other words, if the following request is made:
http://www.example.com/index.php
...eZ publish will behave as if the following URL was requested:
http://www.example.com/index.php/content/view/full/2
No redirection or page reload will be made, which means that the address field of the browser will remain unchanged.
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2013 eZ Systems AS (except where otherwise noted). All rights reserved.