Lucidium - The Guiding Principles
The Problem Lucidium Seeks to Address
The real value of any database application is:
- the way it models the data for the exact circumstances in
question,
- the way it makes its users access and update that data,
and the process logic it applies.
Yet most of the time and effort usually spent creating such
an application goes on:
- writing code to do all the standard jobs such a system
needs to do,
- laying out screen elements: windows, forms or pages.
How We Seek to Solve this Problem
Lucidium captures the essentials of an application as a
configuration. The data model and corresponding process logic encapsulated in a
concise representation of the requirements. A simple set of Java programs use
the configuration to build specific database tables for the application, create
pages and apply the process logic.
Our Guiding Rules
The following ideas guided us in our development of the
platform.
- That a basic set of page patterns (menu, search, display,
update), generated from the data model, can accommodate most situations.
- That every data relationship should be displayed by a
hyperlink, allowing the user to navigate rapidly and directly from one
display page to another, without having to keeping searching for the
related record.
- Every distinct page should be referenced by a distinct
URL, to allow bookmarking, the back button, history, etc.
- All the standard browser functions should be available to
the user.
- Obfuscation is not a substitute for security – keep
everything (including the URL) simple.
- That a browser-based application should divide user
activity into browsing/navigating and making specific updates.
- That every data update should be recorded as part of a
“transaction”, which can be viewed on-line, providing a version history
with comments, an audit trail of before and after values, and a mechanism
to undo mistaken updates.
- Use a simple request/response “interaction model” that works
for both “on-line” (user interaction) and “off-line” (batch) situations.
- That a “request” consists of a set of parameter
name/value pairs.
- That a “response” consists of an XML packet that
represents the page in abstract.
- That the XML packet can be transformed with XSL to work
with all kinds of user agents, e.g. to xHTML for browsers, to VXML for
voice applications, and so on.
- That a simple, well-designed API can provide the developer
with control over the behaviour of components.
The Resulting Application
The application platform is delivered and in use. We feel
that the design goals have been met. A typical custom application can be
delivered in fewer than 100 lines of API code. Development continues on new
interfaces (voice, WAP etc) but the core is tested, stable and proven.
back