Although Radicore comes with a set of working components in the form of the Menu system, RBAC system, Data Dictionary, Audit Logging system and Workflow system, there is nothing like a set of working applications to demonstrate its capabilities. Consequently Radicore is supplied with the following sample applications which are available under the 'Prototypes' menu:
This is just a dummy application which simply tests some of the simple as well as the more advanced features of the framework.
- It has a one-to-many relationship between Person_Type and Person.
- It has a one-to-many relationship between Person and Person_Address, where each Address has a start and end date, with only one address being current at any one time.
- There is a many-to-many relationship between Option and Person, which can be viewed from either Person-within-Option or Option-within-Person.
- It has a flexible tree structure organised into Tree_Types, Tree_Levels within Tree_Types, and Nodes within Tree-Levels.
- Each tree structure can be viewed with nodes that can be individually expanded or collapsed.
This uses a generic database design that attempts to cover most of the features encountered in a product database:
- Products can be identified in a variety of ways: by ISBN, manufacturer's id, SKU, UPC or whatever.
- Products can be grouped into Categories, and Categories can be built into a hierarchy of sub-categories (and sub-sub-categories, etc) in what is known as a Category Rollup. It is possible to search for a Product Category and include the entries for all sub-categories in that hierarchy.
- It is possible to define a list of Features by various Feature Categories which are available for each Product. Each Feature can be defined as one of 'standard', 'optional', 'required' or 'selectable', and have its own start and end date so that different features can be phased in or out over time.
- It is possible to define whether two Features are incompatible with each other or dependent on each other. For example, a range of different colours may be defined as 'selectable', but each colour is incompatible with the others which means that only one colour can be selected.
- For each Product it is possible to define a range of Price Components of various types (basic price, discount, surcharge, MRP) and various frequencies (one time, recurring, utilisation), each with its own start date and end date so that it can be phased in or out over time.
- Price Components can be specified at the Product, Product Feature or Product Category level.
- It is also possible to record various Units of Measure, with conversion tables, which can be applied to Products, Product Features and Price Components.
This prototype is explained in more detail in Prototype Product Application.
This enables a variety of Questionnaires to be created, then to collect answers from users.
- Surveys can be grouped into customisable types, such as 'environment', 'security', 'health and safety', etc.
- Each Survey can have an number of Sections, and each Section can have any number of Questions.
- It is possible to resequence a Section within a Survey, and to resequence a Question in a Section.
- For each Question the answer can be set to one of the following:
- Free-format text.
- A number, with the option of specifying a minimum and maximum value for each Question.
- Multiple Choice, where a different list of choices can be defined for each Question.
- For Multiple Choice answers a particular choice may cause subsequent Questions in the current Section to be skipped, up to the first Question in a subsequent Section.
- A user need not answer all the Questions at the same time, or in a specific sequence. A user may visit a Questionnaire any number of times over a period of time.
- A user cannot mark a Questionnaire as 'complete' until all relevant Questions have been answered, and once marked as 'complete' it cannot be modified unless it is unlocked by a supervisor.
- Once a user has completed a Questionnaire it is possible to schedule another one at a future date.
This prototype is explained in more detail in Prototype Survey/Questionnaire Application.
This has collections of teachers, lessons, students and rooms, the means to define weekly schedules, and the means to display a whole week's schedule on a single page.
- There can be many Teachers and many Lessons.
- A Teacher can give many Lessons, but a Lesson can only be given by one Teacher.
- There can be many Students and many Classes (groups) of Students.
- A Student may belong to a Class, or he may be treated individually.
- Lessons can taken by individual Students or by Classes.
- Before scheduling commences a table of possible conflicts is built to ensure that the same person cannot be in more than one place at the same time.
- Schedules are maintained for each Classroom by allocating a Lesson to a day and a time range. Possible conflicts can be identified immediately from the conflicts table.
- Once a schedule has been built the whole week can be viewed on a single page from different angles - by Room, by Teacher, by Lesson, by Class or by individual Student.
This prototype is explained in more detail in Prototype Classroom Scheduling Application.