Like on most contemporary programming frameworks, the Webasyst kernel implements architectural pattern MVC (Model-View-Controller). The main principle of the MVC pattern assumes dividing an application into three weakly bound kinds of components (layers):
- data management layer (model)
- view layer
- business logic layer (controller) — receipt/validation/processing of user data; receipt of data from the model layer, their pre-processing for use by the view layer to be displayed in user's browser
This approach helps better organize the source code, increases its readability, and facilitates distribution of programming tasks among several developers and further code support (in particular, it allows introducing changes to one of the layers without affecting or insignificantly affecting other layers).
HTTP request processing order
- A request is accepted by the dispatcher script.
- The framework kernel parses the requested URL.
- The routing system determines, which application is responsible for the request processing and what action should be executed.
- The appropriate controller is determined for the action to be executed, which takes over conrol over further processing of the user request.
- The controller executes the requested business logic by reading application data via model classes where necessary.
- To generate the resulting HTML code, the controller consecutively calls methods of one or several action classes.
- Each called action passes on the received data to the template engine.
- The template engine generates the resulting HTML code using the data received from action classes and the appropriate template files.
Database interaction
The technical implmentation of the database interaction consists of two levels: system and application level.
System level
The system level is resonsible for establishing and maintaining connections (connection pool) to a specific database, transmission of SQL queries, and receipt of their results from the DBMS. Its operation depends on the actual type of the database server used; therefore, independent implementation of this level in the form of adapter plugins is required for each DBMS type. The current framework version contains such an adapter only for MySQL.
Application level
The application level is abstracted from the functioning of the specific DBMS and can technically not depend no its type at all. In other words, an application may not depend on the availability of, say, a MySQL server and be able to equally well operate with other DMBS's. In this case it is mandatory to have the corresponding DBMS adapter plugin installed.
The framework offers tools for interaction with the database without the necessity to manually write SQL queries in the application source code. They allow you to abstract from the particular DBMS. Instead of using "raw" SQL queries, an application can call appropriate model methods; e.g., "get object instance with the specified key value", "save object instance", "get object list", etc.
Controllers & actions
The controller layer is divided in Webasyst into two even thinner layes: controllers and actions (this layer actually also includes the dispatcher script and the routing system, but they do not directly affect the application development process).
Controller is a part of an application, which implements the request-processing logic. It is where the structural blocks of a web page are defined, which is displayed in response to a user's request. In complex applications, to improve the readability of the source code, it is advisable to split the web page generation logic into several parts. Each such part (e.g., the one responsible for generation of a single informational block) is called an action.
Action is a part of an application, which is responsible for generation of a portion of HTML code. It can be either the entire web page or a single informational block. An action is always called from within a controller. During the request processing a controller determines, which actions must be called to generate a web page, and calls them one by one. In the very common case, when a page has only one dynamic block (generated by some action), the controller's task is to call only one available action. In the framework there is a default controller, which is triggered when no special controller has been detected for the current request, but the action class required for processing of the current request (as determined by the routing system) exists.
Some HTTP requests may require a certain action to be executed without a new web page being loaded in the browser. The result of such an action can be redirecting to another URL; e.g., after deleting or saving data via a web form. In such cases the entire logic can be implemented in the controller and no extra action classes are required.
Page templates
Each action is associated with a template file used to generate HTML code for a web page. The view layer of the Webasyst framework is by default implemented with the help of template engine Smarty. Of course, it is not a strict requirement to use only Smarty. There is an option to connect other template engines or even use pure PHP code to create HTML templates. To connect a new template engine, it is enough to create an adapter class and add it to the system configuration file.
Applications
Framework Webasyst has been designed so as to allow existence of several applications within one installed framework instance (with common database, address space, users, authentication and authorization system). One of the main goals of creating a framework was to organize tight integration and interaction of several applications. Each application has a unique identifier (APP_ID) within the system. The source code of each application resides in an individual subfolder within the common file system.
Application tables in the database are provided with a unique prefix to avoid table name conflicts. The list of installer applications is contained the system
configuration file wa-config/apps.php.
Users, access rights, authorization, backend, and frontend
Frwmework Webasyst has been designed for development of business-oriented applications in the first place. For this reason global entities such as "contact", "user", and the notion of the access rights are an integral part of the system and are deeply integrated in its architecture. The framework without installed applications already contains a complete infrastructure with the authorization interface, the user management mechanism, access rights setup tools, and a differentiation between the backend and the frontend.
Authentication and user access rights validation are involved in processing of any HTTP request. These operations are performed automatically at the system level and do not require extra efforts from an application developer.
The web interface of any Webasyst application consists of two basic parts: the backend and the frontend.
The backend is intended for use within the organization, to which the installed application belongs. Access to the backend is allowed only to authorized users. This part of the interface usually contains various data management tools.
The frontend should primarily be used by the organization's clients, website visitors, and other persons. This part of an application is published on a website and is usually accessible without authorization. Within the frontend can also exist personal password-protected accounts of registered website visitors; however, access to the backend is not automatically granted to such users). Control over access to the application's frontend is performed by the application and is not managed at the system level. It is certainly not a requirement for an application to have both the backend and the frontend. For example, the Stickies app supplied within the standard framework distribution has only the backend and no frontend.
