RADICORE v2.02.0 released01 February 2017
RADICORE v2.01.0 released01 November 2016
RADICORE v2.00.0 released01 October 2016
The use of Cascading Style Sheets within Radicore22 April 2008
How to implement Two Factor Authentication01 February 2008
Support for PHP4 dropped, support for PHP7 started01 October 2016
Why you should build your web application back-to-front06 January 2013
What is the 3-Tier Architecture?14 October 2012
DB or not DB, that is the question05 March 2017
On not using the "right" standards13 December 2016
Object Oriented Database Programming01 November 2016
What architecture does RADICORE use?
RADICORE architectural overview
Some modules come pre-written and are re-usable, while others need to be created for each application object. The following components are pre-written and re-usable:
- Data Access Object (DAO). There is a separate class for each different database engine (MySQL, PostgreSQL, Oracle, SQL Server, etc) which contains all the code necessary to communicate with that RDBMS. This component will construct all SQL queries based on the information which is passed down to it from the business layer component.
- Abstract Table class. This forms part of the Model in MVC. This contains all the code necessary to read from and write to any database table, plus performing any primary data validation which verifies that all user input conforms to each field's data type. It is called an "abstract" class as it cannot be used on its own - it must be extended into a "concrete" database table class.
- Page Controller. There is a separate page controller for each Transaction Pattern. This deals with all GET and POST requests, communicates with the Model, then passes the results to the View where the data is extracted into an XML document before being transformed into HTML by an XSL stylesheet.
- XSL stylesheet. This forms part of the View in MVC. There is a separate stylesheet for each Transaction Pattern which transforms the XML document into HTML. Each stylesheet is broken down into a series of zones which are filled using data extracted from the XML document. Certain zones, such as the menu bar, navigation bar, quicksearch bar, action bar, pagination area and scrolling areas, are automatically handled by standard code. Each page has one or more zones for application data which are filled using data provided by different Model components.
The following components need to be created for each application object:
Database Table class. There is a separate class for each table in the application database. The initial class can be constructed automatically by importing the database structure into the data dictionary, then exporting it to the application, one table at a time. These details include the following:
- Database name and table name.
- Array of field names and field specifications.
- Primary key details and optional Candidate key details.
- Relationship details (parents and children).
Note that the same table class can be used by any number of different components. The initial class contains all the code necessary to perform basic CRUD operations on that table, including primary data validation. Additional validation can be included by modifying the relevant customisable methods. Once created the table class will not be overwritten by the data dictionary export function so that any customisation will be preserved.
- Screen Structure. Application data is extracted from each Model object and transferred to an XML document where the database table names and field names are preserved. The screen structure file identifies which table goes into which XSL zone, and for each zone which fields need to be displayed and in which order. Note that the same "detail" view can be shared by the Create, Read, Update, Delete and Search component for each database table. The screen structure is identical, it is only he behaviour which is different.
- Component definition. This is a very simple script which identifies which Model, View and Controller is to be used for that component.
This architecture was specifically designed so that most of the developer effort can be concentrated on writing the business rules in the Model component, with very little being required for the View and Controller. No HTML needs to be written, but application pages can be customised through the use of CSS files. No SQL needs to be written, although there are provisions for customising the SQL queries which are generated by the framework by inserting the relevant code into the Model component.