Developers
On this page we will shortly introduce to you the cPEED Framework. You may be getting familiar with the modularity and multi-layer architecture of cPEED, the role of the layers, the implemented standards, and we also want to present you the cPEED Instant Modules.
About the Framework
We have designed a common architecture for the complex web applications. As a starting point the structures and ideas known from the conventional business application development were used, but always considering the restrictions deriving from the web architecture and the prevalent technologies and standards. It is important to pay special attention to the separation of the developer roles (e.g. the programmer and the HTML designer) and to the multilingual environment in which the application is utilized when designing the architecture.
In a higher level, our framework assures the clarity of the developed applications (which is not too simple in case of middle sized sites), be prepared to re-use the code or its parts, and even make it easy to deploy the web application in a new context. In the lower levels it has to span technological difficulties. The most important things are the separation of the presentation and business logic, separation of different logical units, the support for sessions, the tasks of user authentication (by an unified log-in process) and authorization (by permission checking), then simplifying the work with the forms, unifying and accelerating database-driven data management, and simplifying the work with file-resources and their metadata.
The most important task of the code generator is to speed up the development process by completing the repeating tasks, and to eliminate the overhead raised by the framework. The latter includes the tasks of preparing an application, deploying the framework, and creating a skeleton for the different types of files.
It generates the (PHP and HTML) code using the developer's parameters. An integrated development environment combines the generator functions ("wizards"). This IDE is a stand-alone web application on a web server. The most frequently used wizards are: generating business logic in the form of database-using functions, preparing complex data-representation elements (data lists), inserting language-independent texts, creating forms and placing widgets on them, and connecting content validating and event handling functions to the widgets.
The selected script language is PHP. The interpreter is installed on lots of Internet servers. This popularity is owed to the simple administration, moreover the language is easy to use and learn, and the interpreter is free to use. Besides this lots of modules, function libraries are on hand for the programmer. It has all the advantages of the script languages. The source code is preserved on the server, and the execution process does not need any special resources or technologies on the client side apart from a web browser.
The web application architecture
The designed web application's architecture will follow the well-known multi-tier model. This structure is important to help separate the application according to the developer roles. To understand the mechanism of this model, we start with the processes during the serving a request!
The browser would access the files labeled as "PHP pages" on the figure. This files are hard to position on the grounds of the conventional applications' tiers, because their role is mainly to mediate between the presentation and the business logic, so they are situated on the border of the two tiers. For that reason we could call them presentation logic. This files have a well-defined structure. Besides the validation of the user input (forms, etc.), the authorization, and the substitution of the language-dependent elements they do nothing else than calling the appropriate functions of the modules with the actual parameters and then using the HTML template parser.
There are two different types of the business logic modules: The first are the framework's modules doing the general tasks of a web application (as session management, logging, multilingual support, form and resource handling, etc.). The second type modules implement the concrete business logic of the application. The module files are PHP scripts as well, however, they are not bound to specific pages. They contain a class. To use a module one has to include the appropriate file in the script code. The functions of the class are representing well-defined tasks. Only the modules can access the database or other resource files. The actual parameters (e.g. the table or file names) are from configuration scripts.
After have performed the required tasks the web application has to send an HTML answer to the user. To every PHP page belongs one or more HTML template file that is created by a creative designer, and the web application send these back as answer. Of course we are talking about dynamic web pages so the response couldn't be always the same file. So the templates contain special fields that are substituted with dynamic content by a so-called template parser.
The modules are using a database-abstraction layer to access the data. One has to define the actual DBMS in the configuration script. With all of this, a change of the DBMS takes only couple of minutes.