Architecture /

Essentials

Boxary adheres a few Software Design Principles and does not interfere with Visual Design Principles.

Manifest

Boxary is controlled by manifests, specifying attributes and properties, their slots, auto tags.

Proxy

Boxary, as the engine, uses a proxy class to interface to the installed portal software.

Canvas

Boxary uses a drawing area for the graph nodes, also called the WorkArea. A Lexicon class specifies the current context.

Templates

Templating features building app's without php coding. Boxary accepts several syntaxes: {...}, [-], (:...:). Markup is accepted thru plugins.

Elementary Elements.

  • Boxary uses Graphs.
  • Boxary uses Graph Notation.
  • Boxary consists of a compact kernel and a collection of plugs.
  • Boxary is loosely typed; data types are number, string, timeStamp and blob. No floats.
  • Boxary Themes are based on a pattern library.
  • Boxary Skins are css3 only.

Key Jargon.

Boxary uses a EAV model? for structuring data. For most people these terms (entity, attribute, value) have different meaning: one should consider that these terms are often used while different context is applied and therefor have a hidden meaning. This does not evaporate with a visualising paradigm.
Read about slots vs nodes, values and instances?, attributes vs properties, shapes and stamps.

  • Boxary ontonomy uses terms like binder, blend, slot to cope with data models.
  • Boxary uses names like bundle, facet, trove to facilitate walking the ontonomy graph (data model).
  • Boxary taxonomy uses terms like joint, trait, enum to cope with categories.
  • Boxary uses names like category, rubric, bag to facilitate walking the taxonomy graph (data model).
  • Boxary entelechy separates apps by naming jargon with terms like trunk, trove, bunch.

Architecture

The architectural view of Boxary is expressed through a tetractys.
The platform - in software terms - is developed with a Cybernetics approach.