How does RADICORE aid Rapid Application Development?

In order for a framework to legitimately label itself as a RAD framework it should enable the time delay between idea and implementation to be as short as possible. This can only be done if the framework provides the following:

  • A number of pre-built components which perform standard functions.
  • The ability to generate other components which are specific to your application. These components may be basic to start with, but the default behaviour should be easily customised.

The first step is to use an architecture which is comprised of modules which can fall into one of these two categories. The RADICORE framework is based on a combination of the 3-Tier Architecture and Model-View-Controller design patterns, which results in the following structure diagram:

3-Tier Architecture combined with Model-View-Controller

model-view-controller-03a (5K)

It is a true Rapid Application Development (RAD) framework by virtue of the the fact that the components are either supplied within the framework or generated by the framework, thus greatly reducing the development effort required to create working user transactions.

  • All Model components are generated from the Data Dictionary which obtains its data from the database schema and inherits all its standard code from an abstract table class. Each Model is therefore responsible for the data validation, business rules and task-specific behaviour for a particular database table.
  • There is a pre-defined View component which turns data into HTML by first converting it into XML, then transforms it into HTML using one of the supplied XSL stylesheets. There is also another component which produces PDF output. Each of these View objects uses a simple structure file, which is generated from the Data Dictionary, to identify which piece of application data goes where.
  • There is a pre-defined Controller component, one for each of the in-built Transaction Patterns. Any Controller can theoretically be used with any Model.
  • The Data Access Object (DAO) is instantiated from one of the supplied database classes, with a separate class for each of the supported DBMS engines (MySQL, PostgreSQL, Oracle and SQL Server). This object is responsible for constructing and executing each SQL query for any and every table within the database(s).

This enables new application components to be built as quickly as possible using as much reusable code as possible. User transactions are generated by the Data Dictionary from one of the pre-defined Transaction Patterns. This provides the developer with a basic working transaction, or family of transactions, which allows data to be input to and output from the database without the need to write any code - no PHP code, no HTML code and no SQL code. All data is properly validated so that it matches its data type and size as defined in the database schema. Additional validation or business rules can be inserted into the generated class file in order to augment the standard behaviour. The generated screen structure file (for HTML output) or report structure file (for PDF output) can also be customised in order to change which field gets displayed where.

Each user transaction will have its own component script which couldn't be simpler. All it does is say "use this Model and this View with this controller" as in the following example:

<?php
$table_id = "person";                      // identify the Model
$screen   = 'person.detail.screen.inc';    // identify the View
require 'std.enquire1.inc';                // activate the Controller
?>

Do you know of any other MVC framework which can do this?

The RADICORE framework also enables completed application components to be released to end-users as quickly as possible by providing a series of ready-to-use system components.

  1. The MENU system system provides the means to build customisable and dynamic menu structures.
  2. The RBAC system provides the means to build different security profiles for different groups of users.
  3. The Workflow system provides the means to automate the flow between one business process and another.
  4. The Audit Logging system provides the means to record database updates in a log file which can be viewed with a single online enquiry screen.
  5. The Internationalisation facilities allow applications to be deployed in multiple languages with relative ease.

All these needs are satisfied in a single framework which was built specifically with rapid application development in mind. As an example of how this works in practice, take the following scenario:

You have a simple database table and you want to construct components that will let you list (browse) using variable selection criteria, create, read, update and delete individual entries. What are the steps involved?

  1. Create the database table (using the database administration tool of your choice).
  2. Import the details into the Data Dictionary.
  3. Export the details to automatically generate the basic class file for that table.
  4. Use the transaction generation feature to create a transaction of type LIST 1. This will automatically create the following:
  5. Select the LIST screen from the relevant menu button and off you go! This will initially report "no entries found", but simply select the NEW button in the navigation bar to bring up the ADD detail screen. Once you have added some entries you can return to the LIST screen to see the results. You may then select entries and use the other navigation buttons to ENQUIRE, UPDATE or DELETE. You can even experiment with the SEARCH screen to filter the records displayed in the LIST screen.

You should notice that none of the above steps requires the writing of any PHP code, or any HTML and SQL. Customisation is possible as follows:

  • Although it is not possible to modify the HTML which is generated by each XSL stylesheet, it is possible to alter the style (fonts, colours, images, etc) by modifying the supplied CSS file.
  • The default screen structure file which is generated for each task can be customised to change the order in which fields are displayed, or even where they are displayed. The decision on which HTML control to use is specified in the Data Dictionary, or can be overridden in the Model component.
  • It is possible to override the SQL SELECT statements generated by the system by supplying alternative substrings as shown in How to extend the MySQL SELECT statement.
  • The default class file which is generated for each database table can be customised to include any business rules or task-specific behaviour.

As well as not having to write any HTML or SQL, the infrastructure provided by RADICORE will automatically include the following features without the need to write any additional application code:

  • The options on the menu bar are automatically taken from the contents of the MENU table in the menu database.
  • When the user selects an option on the menu bar the infrastructure will deal with that request.
  • The contents of the breadcrumbs area (the second row in the menu bar) is automatically maintained by the infrastructure.
  • The options on the navigation bar are automatically taken from the contents of the NAVIGATION_BUTTON table in the menu database
  • When the user selects an option on the navigation bar the infrastructure will deal with that request, which includes passing any context down to the selected task.
  • In all LIST screens the column headings will be shown as a series of hyperlinks which, if pressed, will cause the data to be re-retrieved and sorted on that column, with automatic toggling between 'ascending' and 'descending' sequence.
  • It is possible to select multiple entries in the LIST screen before using a navigation button to activate a child screen. In this case the child screen will contain a scrolling area which will enable the user to step through each of the selected entries, one at a time, both forwards and backwards, without having to return to the parent screen.
  • The options on the action bar are supplied by the controller, and processed by the controller when selected.
  • The pagination area will be constructed by the infrastructure, which will also deal with any pagination requests.
  • The scrolling area(s) will be constructed by the infrastructure, which will also deal with any scrolling requests.
  • A COPY button will be provided on the action bar of all ENQUIRE, UPDATE and DELETE screens so that data can then be PASTED into an ADD screen.
  • When performing an INSERT or an UPDATE all data will be automatically subjected to primary validation using the field specifications which were exported from the data dictionary.
  • When performing a DELETE all relationships will be automatically checked using the referential integrity rules which were defined in the data dictionary.

By generating transactions from the pre-defined templates a lot of processing is automatically provided "as standard". Complex tasks can be accomplished by creating families of components which are linked together using the navigation bar. The only difficult part is deciding which templates to use, but that problem soon evaporates with experience.