wCMF  3.6
 All Classes Namespaces Files Functions Variables Groups Pages
architecture.doxy
Go to the documentation of this file.
1 /** @page architecture
2  *
3  * @section architecture Architecture
4  *
5  * - @ref persistence
6  * - @ref datarepresentation
7  * - @ref oid
8  * - @ref output
9  * - @ref userinterface
10  * - @ref accesscontrol
11  * - @ref applicationflow
12  *
13  * @note Method/class names in diagrams may vary from the current ones found in the framework.
14  *
15  * @subsection persistence Data storage
16  *
17  * The main task of the framework is to provide an easy-to-use interface to different
18  * (not object oriented) persistence mechanisms (whether they're relational databases or
19  * XML files).
20  *
21  * For this purpose the framework defines the PersistentObject class, which provides
22  * operations for changing, saving and deleting data. This class and its subclasses
23  * are the data's object oriented representation (@em domain @em classes or @em content
24  * @em types in an CMS context), which is used by application developers. The transformation
25  * into relational presentations is carried out by specialized subclasses of PersistenceMapper,
26  * which for instance implement the appropriate SQL commands. The domain objects (instances
27  * of the domain classes) use these classes transparently to the programmer.@n
28  * %PersistenceMapper classes make use of the DataConverter classes in order to convert data between
29  * application and persistent storage. In this way for instance the date format of the
30  * database can be converted to the preferred format of the application.@n
31  * If a direct access to the persistence layer is necessary - for example when loading
32  * objects - the PersistenceFacade is used, which delegates the request to the appropriate
33  * mapper.@n
34  * For relational database storages wCMF uses the <a href="http://adodb.sourceforge.net/" target="_blank">ADOdb</a>
35  * Database Library for PHP as abstraction layer.
36  *
37  * @image html persistence.png "Persistence Classes"
38  *
39  * @subsection datarepresentation Data representation
40  *
41  * At present the framework defines two specialized domain classes, Node and Table, of which the Node class
42  * is the application development's central component. Since data is predominantly organized
43  * hierarchical, this class provides a generic data container, which allows for the building of
44  * tree structures. %Node objects can contain different attributes. This makes the definition of
45  * different domain classes possible (which merely differ in their attributes: @em headline, @em text,
46  * @em image, @em link etc. - not in their functionality). Appropriate mapper classes are
47  * NodeRDBMapper, NodeXMLDBMapper a.o.
48  *
49  * The class NodeIterator is responsible for traversing trees composed of nodes. This class implements
50  * a depth-first algorithm (the traversing follows the structure to the deepest node first before it
51  * continues with the neighboring). Subclasses can implement further algorithms.@n
52  * The extension of node classes with additional operations follows the visitor pattern. Subclasses
53  * of Visitor for instance add behaviour like @em save (CommitVisitor), @em graphical @em display
54  * (LayoutVisitor) oder @em output (OutputVisitor).@n
55  *
56  * @subsubsection oid Object Identifier
57  *
58  * For handling lots of different domain objects an unique identification is crucial. In order to achieve this,
59  * so-called @em Object @em Identifier (@em OID) are used. Various strategies are possible to obtain these identifiers
60  * - for example a central registry. The wCMF composes these OIDs from the type (domain class or type of the
61  * PersistentObject) and a number, which is unique for each type. As an advantage this method prevents conflicts
62  * when domain objects are generated from different database tables and an 'autoincrement' attribute of these
63  * tables is used as the number. Important is, that the object's type can be derived from the OID, because
64  * this enables the PersistenceFacade to deduce the PersistenceMapper for the given object via the configuration
65  * file. The %PersistenceFacade provides methods for composition and interpretation of the OIDs.
66  *
67  * @image html domain_objects.png "Node class"
68  *
69  * @subsection output Data output
70  *
71  * The output format of the nodes (e.g. when using the OutputVisitor) is specified in the corresponding
72  * OutputStrategy. Examples are the XMLOutputStrategy for converting data to XML format for use in
73  * @em Flash movies for instance or further processing via XSLT, TreeViewOutputStrategy for creating HTML
74  * Treeviews or DotOutputStrategy for use with @em dot, which generates a graphic representation of the
75  * data.
76  *
77  * @image html data_output.png "Data output classes"
78  *
79  * @subsection userinterface User interface
80  *
81  * The user interface of a wCMF application is based on the @em Model-View-Controller (@em MVC) pattern.
82  * According to this pattern the application instanciates a specific controller for each action,
83  * which loads the data (model) required for that action and - where applicable - presents the data
84  * to the user via the corresponding view. Upon execution of a controller the next action will
85  * be determined. This could either depend on the result of the action (@em successful, @em failed etc.)
86  * or explicitly be specified by the user (@em save, @em delete etc.). The application flow is defined
87  * by stringing together controller-action pairs.
88  *
89  * The ActionMapper - configured via a configuration file (see @ref configuration) - controls the application
90  * flow. It creates @em controller objekts, which execute actions like @em save changes, @em add
91  * elements, @em delete elements or @em display data - where applicable - with the help of views. For
92  * execution the Controller baseclass defines an algorithm, which is implemented by specialized
93  * subclasses.@n
94  * The @em model, which the controllers work with, is constituted of the domain classes - in most cases
95  * a tree structure of Node objects.@n
96  * The framework uses the <a href="http://smarty.php.net/" target="_blank">Smarty</a> Template Engine
97  * to create the @em views. This means, that a view is defined by a @em Smarty template (*.tpl file),
98  * which is displayed by an instance of the class View. Before the data is displayed the controller extracts
99  * it from the model and assigns it to the view instance.
100  *
101  * @image html mvc.png "MVC Classes"
102  *
103  * @subsection accesscontrol Access control
104  *
105  * Permissions for controller(|domain class|OID)-context-action triplets (see @ref configuration) are
106  * configured based on roles (defined in the data storage). Several users can be assigned to one role
107  * and each user can be assigned to different roles. The assignment of rights is made in the configuration file.
108  * Here permissions can be explicitly granted or denied. During the application flow authentification/
109  * authorization is accomplished by the RightsManager together with a representation of the current user (as an
110  * instance of the AuthUser class, which is created upon successful login and added to the session data).
111  *
112  * @subsection applicationflow Application flow
113  *
114  * To run the wCMF in a web browser a PHP script is necessary as entry point. This is similar to a
115  * @em main method, which instanciates the initial application objects and hands the control over
116  * to these objects.
117  *
118  * In our case this script is @em main.php. It receives parameters (@em controller, @em context, @em action, @em data)
119  * over a HTTP request. These parameters could for instance origin from the previous view. They are made available
120  * to the %ActionMapper in form of an Request instance using the method ActionMapper::processAction. The %ActionMapper
121  * then takes over the control of the application flow and returns after finishing its task or displaying a view, respectively.
122  * Display of a view always interrupts the application's flow and allows the user to interact. The view sends the data obtained
123  * during the interaction (e.g. form data) as HTTP Request back to the script @em main.php.@n
124  *
125  * For each call of the method ActionMapper::processAction the %ActionMapper on his part instanciates an appropriate
126  * controller object, which is supplied with data by Controller::initialize and executed by Controller::execute.
127  * The Controller baseclass provides in its method @em execute the algorithm for validating the data - and if
128  * applicable - initializing the view. Concrete controller classes execute their specific tasks in the method
129  * Controller::executeKernel.
130  * If no view is assigned to a controller, the @em execute method returns @em true. The execution result is stored in the
131  * Response instance, which again is converted into a Request instance and passed to the next call of the %ActionMapper's
132  * @em processAction method. Thus it's possible to cascade different controllers to compose complex tasks out of several simple.
133  * Otherwise the controller assigns the model to the view, which is then displayed by the view with its template (here @em view.tpl).
134  *
135  * Request and Response instances are interpreted using IFormat implementations. This allows the framework to realise
136  * different formats for sending and receiving data. Known formats are HTML, JSON and SOAP.
137  *
138  * The configuration of the controllers, views and actions is done in the configuration file (see @ref configuration).
139  *
140  * @image html mvc_sequence.png "Application flow"
141  *
142  * Back to the @ref intro | Next section @ref extensionpoints
143  *
144  */