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
On not using the "right" standards13 December 2016
Object Oriented Database Design01 November 2016
How NOT to Validate Data02 April 2016
How is RADICORE unique?
The product is unique among PHP frameworks for the following reasons:
- It is aimed at restricted-access back-end administrative web applications, not unrestricted front-end websites.
- It functions with both PHP 4 and PHP 5, unlike some other frameworks which are PHP 5 only.
- It is a proper framework and not just a collection of libraries.
- It provides a toolkit for building components as well as a framework for running those components.
- It is a true Rapid Application Development (RAD) framework where the 'R' stands for 'Rapid' and not 'Retarded'.
- It is based around transaction patterns, not design patterns, which greatly assists in the development of UI components.
- Each transaction pattern provides basic facilities as standard which do not require further action by any developer - menus, security, navigation between components, the passing of context between components, pagination (for list screens), scrolling (for detail screens), column sorting, copy and paste buttons, etc.
- It has a transaction generation facility which automatically creates the necessary components for a transaction using nothing more than the name of the database table and the name of the pattern.
- It enforces a strict separation of UI logic, business logic and data access logic.
- It enables basic, fully functioning components to be created without the need for the developer to write any HTML or SQL.
- It uses a Data Dictionary which expands on the information schema within the RDBMS to provide additional information for use by the application. An 'import' function will extract information from the database schema and write it to the data dictionary while a separate 'export' function will create the files which makes this information available to the application components.
- Business layer components, which are based around database tables, are initially created by the Data Dictionary 'export' function. The use of inherited code enables these to be used to perform standard CRUD operations on the database without the need to write any SQL.
- All HTML output is created by XSL transformations which can be performed either on the server or the client (if the client has an XSL-enabled browser).
- The style of all HTML output can be customised through the use of CSS files. Additional CSS files can be created and placed in the relevant directory from where they can be selected as the user's preferred style.
- Instead of HTML output there are transaction patterns available which can produce output in either CSV or PDF format.
- All SQL query strings are generated at runtime within the Data Access Object using information generated from the Data Dictionary. The standard SQL can be customised within each business layer component.
- Information which is maintained on relationships in the data dictionary allows the framework to automatically generate the necessary JOIN clauses on sql SELECT statements. The relationships may involve multiple columns, multiple relationships between the same two tables, and even self-relationships.
- No database stored procedures or triggers are used, so the use of standard SQL makes it DBMS-independent.
- It includes facilities for Internationalisation (I18N) by keeping all text for different languages in separate files so that different translations can be provided without having to change any core software.
- It includes a fully functioning Role Based Access Control system which provides the ability to define who has access to what within the system. Users are grouped into roles so that the same access restrictions can be shared by many users.
- It also includes a variety of additional security features which may be required by your application.
- It includes an integrated Menu system which allows the required menu structure to be maintained within the database, not program code, which makes it dynamic instead of static. It uses information from the RBAC system to automatically filter out any options which the user is not authorised to access.
- It includes an integrated audit logging system which will allow any database updates to be written out to the audit database. These can then viewed using a standard set of screens. Individual database tables can be included or excluded from the audit process by a simple yes/no switch in the data dictionary. There is no need to customise any audit tables, database triggers or audit screens.
- It includes an integrated activity-based workflow system, designed around Petri Nets, which will enable the application administrator to define workflows to automatically pass control from one task to another when the correct conditions are met.
- It includes automatic session management to maintain the state of the application between requests. This allows, for example, one script to be suspended while another is processed. When a suspended script is reactivated it will resume it processing from where it left off.
- It is also possible for multiple independent sessions to be active on a single client device.
- It includes an online HELP facility which provides access to the contents to the HELP_TEXT table for the current task. Tasks to maintain the contents of this table are provided in the framework. This text may also be provided in multiple languages.
- It includes the ability to hold initial values for certain tasks on the database so that different users can have different values. These can either be specified for individual users or groups of users (roles).
- It includes the option for a multi-tenancy database where you can maintain data for multiple accounts, but where users of each account cannot see the data for other accounts.
- It includes the option to prevent simultaneous updates to the same database record by different users.
- It includes the option to prevent database records from being amended or deleted by anyone other than the record's creator.
- It includes the ability for a Message of the Day (MOTD) to be shown automatically after the user passes through the logon screen. Messages can be maintained by any user with the correct privileges.
- It includes the ability for users to add frequently used tasks to be added to the favourites area of the Home Page. This will allow the user to activate a task from that page instead of having to navigate to a sub-menu.
- It includes the ability for users to maintain their own list of To-Do items which will appear on the Home Page when they become due. It is also possible for entries to be created programmatically, such as when an inventory transaction detects that the stock level for an item has gone below the threshold and should be re-ordered from the supplier.