Who can benefit from RADICORE?

RADICORE is not for end-users who hope to build applications without the aid of programmers, nor is it a tool for novices. If you are already an experienced application developer but want to try a tool that can help you build your applications at a faster rate and with more features, then RADICORE could be worth looking at.

As an absolute minimum you are expected to have the following:

  • Knowledge of the PHP language (doh!).
  • A development machine with the following:
    • A working web server such as Apache. If you don't know what a web server is then RADICORE is not for you.
    • A working RDBMS, one that is supported by Radicore (go here for a current list). If you don't know what an RDBMS is then RADICORE is not for you.
    • Radicore uses a different database schema for each subsystem, so it will be a waste of time loading it into an environment which only allows a single database.
    • A working script which outputs "Hello World". If you cannot even achieve this simple task then RADICORE is DEFINITELY NOT for you.
    • It may also be extremely useful to have a proper IDE with an interactive debugger instead of a plain vanilla text editor.
  • The ability to design an application. You cannot just play with RADICORE and hope that an application will mysteriously materialise out of thin air. If you don't know what "designing an application" involves, then RADICORE is not for you.
  • The ability to design and build an application database which is properly normalised. This will enable the database structure to be imported into the Data Dictionary so that it can be used to generate the components in the business layer. If your database structure is wrong then all of the components in the business layer will be wrong, and not even RADICORE will be able to make a silk purse out of a sow's ear. If you don't know what "normalising a database" means then RADICORE is not for you.

Prior knowledge of the following technologies is not required as RADICORE either comes with them built in, or constructs them automatically:

  • (X)HTML - all the output is generated automatically during the XSL transformation process, so there is no need (or even the ability) to include any HTML code in any component.
  • CSS - all style in the HTML output is controlled through CSS files, and a default file is supplied with the product.
  • XML - all XML documents are generated dynamically by standard code within the framework and passed immediately to the XSL transformation process, so no developer intervention is required. XML documents can be written to disk to aid in any debugging.
  • XSL - a comprehensive series of XSL stylesheets are delivered with the product and are available for immediate use.
  • SQL - all query strings which access the database are constructed at run-time using standard algorithms. There is the option to have all query strings written to disk to aid in any debugging, or to see what is currently being generated so that it can be customised.
  • PDF - if output is required in a printable format then pre-built transaction patterns will do it for you. All that is needed is a simple script which identifies which piece of data goes where on the output document.

The following areas of customisation are available (to people with the relevant skills):

  • The "look" of the application may be customised by amending the CSS file. It is possible to provide a library of alternative CSS files as the framework has the facility which allows each individual user to select the one that he/she prefers.
  • Individual SQL SELECT statements may be customised by supplying alternative values which will be used instead of the defaults.