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
The name RADICORE is a combination of RAD (Rapid Application Development) and CORE (heart, or centre). It can be used as the heart of any number of applications, as indicated in the following diagram:
The structure of RADICORE
RADICORE is not a clone of any existing framework written in any other language, nor does it use any framework components from any third party. It is totally 100% unique. It has been specifically engineered with Rapid Application Development in mind after the author's decades of experience with similar frameworks in other languages. This has given the author the ability to abstract out all the functionality which is independent of any application so that it can be used as the front end for any application without requiring any modifications.
RADICORE greatly reduces the time (and therefore cost) of application development because of the following:
- Developers are spared the chore of designing and coding individual transactions as these can be quickly constructed using the pre-supplied library of Transaction Patterns These can deal with single tables, one-to-many relationships, many-to-many relationships, and hierarchical tree structures. There is now an automated process for generating transactions which enables the delevoper to push a button instead of writing large amounts of code.
- Developers are spared the chore of writing code to handle the communication between related components. When a forms family is constructed from the standard Transaction Patterns the framework will automatically handle the passing of any context between the parent form and child forms, and will automatically return any results back to the parent form when the child finishes.
- Developers are spared the chore of writing any HTML as this is all generated from the XSL stylesheets provided. There is a library of different stylesheets which deal with different page structures. All that is required is a tiny screen structure script which identifies which fields are to be painted on the screen, and in which order.
- Developers are spared the chore of writing out SQL statements for standard operations as these will be automatically generated by the framework at run-time using the information which was exported from the Data Dictionary. The only time developer intervention is required is when the standard behaviour needs to be modified.
- Developers are spared the chore of writing code to put data into the screen. The contents of an object's data array will be extracted by the framework, formatted if necessary, inserted into an XML document, then transformed into HTML by an XSL stylesheet. Any data validation errors which have been generated within any object will also be extracted, added to the XML document and processed by the XSL stylesheet to appear next to the affected field.
- Developers are spared the chore of writing code to filter the user's input as it is automatically validated by the framework using the information which was exported from the Data Dictionary. The only time developer intervention is required is when additional validation rules need to be processed.
- Developers are spared the chore of writing code to deal with database relationships as the framework is able to use the information which was exported from the Data Dictionary to handle JOINS to parent tables. This mechanism can deal with relationships involving multi-field keys, multiple relationships between the same two tables, and even where a table is related to itself. The only time developer intervention is required is when the standard behaviour needs to be modified.
- Developers are spared the chore of designing and coding their hierarchy of menus as RADICORE comes supplied with a pre-built MENU system which allows menu pages to be constructed and maintained using a standard set of online screens.
- Developers are spared the chore of designing and building a security system as RADICORE comes supplied with a pre-built RBAC system which allows access control lists to be constructed and maintained using a standard set of online screens.
- Developers are spared the chore of designing and building auditing software as RADICORE comes supplied with a pre-built Audit Logging system which allows auditing to take place without the need to construct any additional audit tables or database triggers. All database changes are automatically written to the audit database whose contents can be viewed using a standard set of online screens.
- Developers are spared the chore of designing and building a business process automation system as RADICORE comes supplied with a pre-built Workflow system which allows various workflows to be defined which will then be automatically processed by the framework. The status of each workflow case can be viewed using a standard set of online screens.
- Developers are spared the chore of designing and building software that can easily switch to a different language for international users as RADICORE comes supplied with in-built capabilities for Internationalisation (I18N). All screen labels and error messages are obtained from external files, one per language, so dealing with a new language is as simple as creating a new file in the relevant language directory. The integrated HELP facility will also access its files in the user's designated language.
- Developers are spared the chore of writing code to deal with session management as it is all taken care of by the framework. All data pertaining to a script, such as selection criteria, sort order, page number, etc, are maintained in a persistent store so that it is available throughout the life of a script. This enables any script to be suspended while another is processed. When a suspended script is reactivated it will resume its processing from where it left off. It is also possible for multiple independent sessions to be active on a single client.
- Developers are spared the chore of writing huge amounts of code when output is required in formats other than HTML. The framework contains pre-built Transaction Patterns which can provide data in CSV format (which can be imported into a spreadsheet) or PDF format (for printed reports).
RADICORE also comes with a set of prototype applications which help demonstrate its capabilities. These prototypes show how the various Transaction Patterns, when used in particular combinations, can achieve useful results. They also contain plenty of examples of the custom code which is necessary to enforce a wide range of different business rules.
- What are Transaction Patterns?
- What is the Menu system?
- What is the Role Based Access Control system?
- What is the Workflow system?
- What is the Audit Logging system?
- What is the Data Dictionary?
- What Internationalisation facilities are there?
- What architecture does RADICORE use?
- How does RADICORE aid Rapid Application Development?
- How is RADICORE unique?