Components directory structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This document explains the directory structure for the ezcomponents_ repository which holds the eZ publish Enterprise Components. The following structure is used. DESCRIPTION =========== Holds a short description for the component. design/ ======= Contains the general design documents for the components. This describes the transition from eZ publish 3.x and PHP 4.x to the new components as well as the overall design of the new components. docs/ ===== Contains the general documentation, guidelines and standards for all the components. packages/ ========= The various compoents are present here. Each component consts of subfolders which signify the various branches, each one will have the *trunk* folder which is the main development. Inside each branch the following structure is used: docs/ ----- All documentation for the component in the form of .txt files written in reStructuredText_ format. The following files and folders should be present. readme.txt ^^^^^^^^^^ Description of the component. It should start with a brief description that should make it clear what the component does, then followed with a more detailed description. examples/ ^^^^^^^^^ Contains example PHP classes and supplementary documentation. design/ ------- Contains all analysis and design of the component in the form of textual descriptions and UML diagrams (XMI and PNG). Allthough it is up to the component what is placed here it is recommended to create the following files in the directory. requirements.txt ^^^^^^^^^^^^^^^^ Explains the requirements the components must fulfill. This should be seen from the view of an external person for instance a third party developer or an end-user. Some topics to explain are purpose of component, requirements and goals. design.txt ^^^^^^^^^^ Detailed description of the component which can be read by external developers to understand its inner workings. This will also be used by the implementor of the components. This document must describe all the algorithms that makes the component work. In addition to this document a series of UML diagrams must be employed, the diagrams will help the reader to get a better sense of how the diagram works. The following diagrams should be used: - class diagrams This gives an overview of the classes and their relationships (dependencies, composition etc.) as well as details of their properties and methods. Using multiple class diagrams is adviced for larger components, for instance one large diagram with relationships but without details and then multiple smaller diagrams with more details. - activity/sequence diagrams The activity and sequence diagrams helps developers understand how the functionality in the component actually works. The activity diagram is used for general overivews of the operations that will take place while the sequence shows the operations in more details with methods and data. - state diagrams The state diagram helps understand the inner state of classes. This can help understand what is allowed in one state and what will happen if something illegal is tried (exceptions). .xml ^^^^^^^^^^^^^^^ This is the UML export of the component export from Enterprise Architect. This file can be imported into Enterprise Architect or other UML programs. Make sure that this file is only export from Enterprise Architect. src/ ---- This directory contains all the source files (PHP classes) for the component. .. _ezcomponents: http://svn.ez.no/svn/ezcomponents/ .. _reStructuredText: http://docutils.sourceforge.net/rst.html .. Local Variables: mode: rst fill-column: 79 End: vim: et syn=rst tw=79