Architecture

The architecture of InstantView® consists out of 3 layers: a layer of C++ model classes, the runtime environment and the declarative GUI layer. Instances of C++ classes may be hold in RAM as transient objects as well as persistent objects in the database. The runtime layer passes data back and forth from GUI to database and is also responsible for flow control and message bus. Across all layers a security management and a transaction handling is active. Application programming reduces to InstantView® scripting of commandos being executed during runtime and declaration of the GUI. Data binding in between GUI and model data can be directly described with the GUI declaration.

The separation between the visualization and the model conforms to the MVC concept but with slightly different and more advanced objectives: The program code of a (model) object stands for stable, highly reusable functionalities reflecting the general knowledge of the application area and rarely changing. In contradiction to this, the InstantView® scripting describes the characteristics of a specific application to allow for the creation of individually adjusted software based on standard software. InstantView® scripting is not only the user interface for an application. It also provides the "connecting pieces" (flexible relations between objects, check entry data before passing on to a model object,...) InstantView® script can be organized as encapsulated modules with inheritable attributes. Every module should be responsible for a particular task (such as data maintenance) and therefore represents a sub-application. Modules communicate via message bus, provided by the runtime. Application modules altogether are called AppsWarehouse®, referring to a sub-application "warehouse", providing any required application solution. InstantWeb displays all InstantView® script 1:1 as HTML.

Interaction with the GUI

InstantView^®Script describes window resources that are transformed into real window objects and are therefore being displayed. Messages that have been received by the GUI are translated into logical events (System-Events in InstantView^®). Logical events start the action list algorithms.

Just like every other event-driven program, InstantView^® stays in a program loop on basic system messages (MS Windows). As soon as the user clicks a button, selects a menu item or does anything similar, InstantView^® receives a message for the respective window object (the button, the menu item, ...) and translates it into a logical (and therefore platform-independent) event. Then, the window object action list is browsed.

In case there is a statement sequence, which is connected to the logical event, it should certainly be executed. This does happen, but not immediately. A time-consuming process could possibly start - but InstantView^® answers a basic window system message in this moment! Therefore, the action is temporally uncoupled: The InstantView^® statements pass a waiting line. This detour is transparent for the InstantView^® programmer, but it allows to define any action for a system event without worrying about time conditions.

The following image shows the connection message - logical event - action for a window with button. Pushing the button changes the window title, in this simple example the window title is set into parenthesis:

Parameter Stack

InstantView^® statements exchange parameter and result via stack. Each statement consumes a defined selection of stack entries and puts the results back into the stack. The following image shows the stack setting for our example above:

InstantView^® automatically removes data that is left in the stack by an event-triggered statement sequence. Stack data or data in variables take up memory. This memory is free, as soon as the entries are taken out of the stack or are assigned to other value variables. Once in a while, InstantView^® starts a garbage collection process to win back such memory.

This happens automatically for all fundamental data types (integers, strings, multiple string, ...), so there is no need to worry about this process at all. But also memory, which has stored a transient object X once, shall be de-allocated. The garbage collection algorithm can't determine - at least not in this release - , whether X is referenced by another (transient) object Y.  For as long as X and Y are in the stack, or assigned to variables, everything is fine. If then only X is de-allocated, Y receives a reference to a non-existent object after the next garbage collection. There are two possibilities to avoid this:

• Make sure, that the referenced object X is kept in a variable (as long as Y exists)
.
• Exclude X from the garbage collection (see CreateTransObject) and de-allocate it later (with DeleteObject). This problem also affects (transient) objects as a function return value: The signature that has been specified in the MDI decides, whether InstantView^® excludes the object from the garbage collection or not.

Interaction with Model Objects

Model objects are C++ class instances. Therefore, there is no inherent possibility to access data and methods during runtime (with code other than C++). Since InstantView^® needs exactly this kind of access, model classes can be upgraded by a Data Dictionary (DDI) and a Method Dictionary (MDI).

InstantView^® contains statements, which bring data out of an object into the stack or save data from the stack into an object. The DDI describes, which relations are producible between objects and InstantView^® (and therefore guarantees for referential integrity). It is the base for intelligent mapping between model objects and window interface via access paths (see FillWindow and DrainWindow).

Object functions can be called with the statement Call, in case they are registered in the MDI. This also applies for function calls within an access path. (DDI, as well as MDI are automatically generated with Utility GENDDI).
 

Interaction with the Object Manager

When InstantView^® wants to generate / delete a persistent object, start a query  etc., it doesn't directly ask the object-oriented database for these services. Instead, it addresses the Object Manager. ClassiX^® plans the database structuring into layers and domains. Objects can be saved in different physical databases.

The file CLASSIX.INI describes the database layout. Only the object manager 'knows', where to store a certain object and where to recall it.
 

Message Passing

Sending a message (with SendMsg), InstantView^® first browses all module action lists, then it browses all window objects for statements, which are connected to this message. All located statements are executed immediately. Only the currently open windows and their child objects can receive a message. Therefore, when a message shall open a window, the according statements have to be assigned either to a module, or to another window, which is already displayed on the screen. The message-sending window object can also belong to the message receivers.

How does a message transport further information? The first statement of a sequence, which has been activated through a system event, sees an empty stack. This doesn't necessarily apply for the first message-triggered statement. The receiver sees exactly the same stack setting as SendMsg. SendMsg takes all entries out of the stack. Message receivers can return values from their stack to the sender, using the statement ReturnValue. The same statement sequence can be triggered by system events and messages. Message receivers can leave data only in the stack (InstantView^® removes them automatically).


SendMsg distributes its messages like a newsletter. Setting up a protocol, where the receiver answers the sender directly and privately, the primary message needs to contain the sending window object, other than just further files. A window object is put into the stack via statement widget. The receiver can answer selectively with ReturnMsg.