Welcome to the Okklusion Documentation Site


Okklusion is about Groves, about Trees with Nodes and Leaves, about Entities with Attributes and Relations, about Graphs with Vertices and Edges, and more. Okklusion is about Legacy too, renaming that as proven concepts. For detailed information, please refer to the inofficial Wiki (n.a.).


Okklusion processes the xml defined grove/tree in a legacy way:

Input
Applications must initialize and locate their input. Initial inputs (parameters) may come from xml, from other applications in the tree, from configuration or from an integrated clipBoard.
Processing
Applications do process their input and invoke other dataSources. Streams can be defined using dataProviders, using eventListening or simply using SQL.
Output
Applications do produce some output. Which can be piped to other applications, rendered in a html page, logged somewhere, pushed on the Bus.

The use of CRUD forms is designed as an option.
A builder is available for the task commonly refered to as Scaffolding.

A typical okkluded system is structured in a (tree) hierarchy:

  • Facade : an application that selects the domain application of the request.
    • Holon : the domain application, optional controlling the next level(s).
      • Subject : a specific entity within the domain model.

  • Operation : an action, f.i. Create, Retrieve, Update, Delete.
    • Step : in case of a data collecting form.

The RbacAdmin application (a Holon) is built this way.

The resulting Tree is defined in xml and can be processed in a hierachical way, in an iterative way, can be searched, manipulated, and above all: can be automagically documented.

In other words: the grove/tree is traversed by Okklusion in either a postOrder, preOrder or inOrder way for each IPO method. Besides the composition of the grove/tree, the modelling effort for the system can be carried out in several ways: Okklusion connects to any notational development methodology, be it legacy or state-of-the-art.

Okklusion enables BottomUp development strategies. Components can be reused instantly when a need arises. Even complete application trees can be pasted with ease anywhere. Tune all this thru the xml definitions only.

  • Node : encapsulates Algorithms plus Data into a Context
    • Tree : consists of an Entity plus an Application giving a Layout (do not confuse with MVC)
      • Grove : optional; a bunch of trees, a precursor of the DOM tree. Used as a concept for a Data Model; connects to a Document -> Task / GUI

  • Holon : a dependant whole; though complete, it needs fitting inside a bigger system. Also known as a subsystem concept; mostly modeled as Input -> Processing -> Output

Okklusion integrates with several ORM layers and/or DB layers, available in Open Source:

There is no PEAR dependency.
To build the target website Phing is used.
For the moment Smarty is used as template engine.


Overview

  1. A webbrowser sends a HTTP request to the webserver.
  2. The server pushes the parameters of the request to Okklusion; amongst them FORM parameters, URL-encoded parameters, Cookie variables.
  3. Okklusion starts the execution of the application(s). These applications (Tasks) delegate specifics to Okklusion:
    • retrieve common configuration values,
    • authenticate and/or authorize,
    • validate / filter FORM fields,
    • execute database queries,
    • invoke Logger(s),
    • construct and execute an (additional) task hierarchy.
  4. Finally a template is called (not shown), with parameters collected by the application(s). This template is converted to (X)HTML.
  5. The constructed HTML document is sent (response) to the webbrowser. This HTML document contains hyperlinks to resources (javaScripts, Applets, images, etc) needed for a correct display.

Please send comments to slipStream <at> okklusion <dot> ovh.