Catviz Manual

The TDateField uses Mihai Bazon's excellent JavaScript DHTML pop-up calendar (from students.infoiasi.ro/~mishoo/site/calendar.epl).

The penguin icon graphics in the Aqua team are the excellent work of Everaldo Coelho (www.everaldo.com)

The Treeview Javascript is a package called dTree which is the excellent work of Geir Landrö (www.destroydrop.com/javascript/tree/)

Although Catviz is a newly built content manager phpWebSite has been an inspiration in many ways. Without my previous experience with phpWebSite Catviz would not be what it is today.

Catviz is a PHP/MySQL based content manager. Its primary aim is to provide a rich platform for the development of interactive websites.

It is very different from any other PHP/MySQL content manager because of the following features:

The functionality currently available is:

Catviz is developed on a RedHat 8 system with Apache 2.0.40, PHP 4.2.2 and MySQL 3.23.52. I would recommend to switch register_globals off for security's sake. There are no external requirements.

Installation is pretty straightforward. All settings are in conf/config.php. Check all settings in this file and point your browser at [yoursite]/install/install.php. This creates the database for you. Make sure the var/ tree is writeable by the web server (e.g. the 'apache' or 'http' user)

The control panel gives access to the administrative functions of each module. A subset of modules may show up depending on your access rights. A typical one is shown below:

The module manager allows switching modules on and off, as well as installing new modules. The Module Priority allows you to determine the order in which module is loaded/instantiated. The module manager needs to be the first one - The menu module needs to be loaded after all the modules it refers to are loaded. Each module has a set of Access Classes which are used for the security system.

Each user has to be entered through this interface, there is no self-signup procedure yet. Each user is automatically a member of 'Everyone' (once logged in), you don't need to make users a member explicitly. The user administrator is also used to define document classes., see the security section below. Each module defines a set of access classes. The ones that are curently present are:

This simply shows a full list of news articles, regardless of their status, allowing the News admin to edit ore delete them.

The approval administrator collects items to be approved from all modules, and shows the resulting overview. Click on each item to show a form which allows the content to be approved or rejected. This form is different per module as each module delivers it's own inerface.

The webpages administrator shows a full list of the webpages, allowing the webpages admin to edit or delete them. Alternatively, you may use the edit icon whis is shown in the title bar of the webpage when you have edit rights on the page shown. You can prepare a webpage offline and paste it in here. When you are using images, put them in the same directory as your HTML document and upload them (in the file list). The filenames will be automatically corrected in your webpage to show up correctly in Catviz.

The module administrator shows a list of menu items. You can add/edit/remove these items. Some items are not shown by default but activated by the corresponding module. When your menu item points at a form, Catviz checks if you have the appropriate rights, and does not show the menu item if this is not the case.

Catviz consists of a class library (catviz_lib.php), a small core module controller (index.php), a set of modules which provide the standard functionality, and a set of templates. Each module is represented by a class that is a descendant of TModule. Each module contains forms (TForm descendants) and fields (TField descendants).

The content of each form is mapped on a content variable. A template determines where each content variable is placed on the generated page.

When a connection is made to a Catviz server the first time, a session is created (Catviz-Content-Manager). The session store contains a formstack, the catviz_info object and a an array of module objects. In each module the 'static' forms are created and each 'static' form is instantiated as an object in the module object (this is repeated each time a user logs in our out). Then, the action method of each module is called, and finally the layout manager creates the page to be shown. Most forms are generated on the fly to speed up the initial connection and to minimize the session store space usage.

Each form is uniquely identified by the combination of modulename and formname. Each form has a number of actions it can perform, such as 'edit', 'show', 'submit'. To show a particular form the following parameters are needed:

The database ineraction requires a few things in the database design. A unique identifier is needed for each row in each table, and that identifier needs to be numeric and auto incrementing. The name is something_id (that'st not a system requirement but a naming convention). Foreign keys in tables need to be named after their keyfields in the master table for the master/details views to operate properly.

Tables for modules are named mod_modulename_... toa avoid collisions of tablenames between modules.

The security system consists of 3 parts: the user manager, the forms access control and the data access control.

The templating system is integrated with the forms, so variables do not have to be translated and even form methods can be called from the templates. Each template is divided into sections. Each section is separated by special formatted HTML comments, to allow any HTML editor to edit the templates without a problem. Sections start with <--&sectionname--> and end with <--/sectionname-->. Each section is processed in a sequence determined by the form code. So even when you have foorter before header for example, header still comes out first. HTML outside the section markers is not used at all. You can add HTML outside the tags if that helps to keep your HTML editor happy. Inside each section form elements are placed using curly brackets around fieldnames, like:{fieldname}. Methods of the form class and variables in the form object can be called using {!functionname()} or {!variablename} These are evaluated as the form is generated. The form definition file is read at form creation time, split into sections and stored in the session store. This way re-interpretation is prevented. As a consequence, When you change a template it will only take effect when the forms are re-initialized (log in as other user, drop session). There are 3 levels of templates: the page template, the box template and the form template.

Each module lives in a subdirctory under /mod. The following subdirectories are present:

The coding standard used is the standard described in the PEAR documentation with a few additions.

Indents are 4 spaces wide.

Class names are of the form T[Name]. Module class names have the form MOD_[Name]

Instances of modules (module objects) are named mod_[name]

Class names always start with a capital letter.

Class methods and functions are named using the 'camel' convention, e.g. lowercaseCapitalizedCapitalized.

Attribute names are all lowercase with underscores where needed.

Documentation is generated using PHPDocumentor (phpdoc.org). A small reminder for myself what command line is needed: php phpdoc -t [targetdir] -o HTML:Smarty:default -d [classdir]

The main code lives in php/MOD_[modulename].

class MOD_mymodule extends TModule{
var ...

/**
* Constructor for the MyModule class
*
*/
function MOD_mymodule(){
TModule::TModule("mymodule");

}

function initializeForms(){
Tmodule::InitializeForms();
.
.
.
}

function initializeForm($formname){
switch ($formname){
/**
* Create the Webpage edit form
*/
case 'webpage_edit':
.
.
}
}

$thefields=array("first_name","last_name","address","phonenumber");
$this->forms["edit_addressbook_entry"]=
&new TDBEditForm("addresbook","edit_addressbook_info",$thefields,"mod_addressbook","","address_id");

The webpages module provides a mechanism for maintaining and displaying webpages and blocks. Pages are structured in a tree structure which is visualised by a DHTML/Javascript tree (using dTree by Geir Landro). The structure is created with a multi-admin and multi-usergroup scenario in mind. Typically, this is used in an Intranet environment where various persons/departments manage their own part of the site.

In normal view, the tree shows all pages which are 'active' (flag in mod_webpages) and which have a document_class for which you have read rights.

For someone who has webpages_user rights all inactive pages show as well. A webpages_user is in fact a webpage author. He can only create pages with a document_class for which he has write rights. The parent page can only be a page of a class for which he has write rights. Sounds complicated? It simply comes down to the authors administering their own tree.

Users with webpages_admin rights can create root entries.