DataModel /

DataTypes

A pattern library featuring Shape -> Stamp -> Slot -> Templet

Boxary does not rely on abstract dataTypes and uses a terminology that expresses the visual approach. In general a data item has a shape, a form. This shape is stamped with the data. Shapes and Stamps flow thru a Slot into a Templet.

Compare a date/time with a linux timeStamp: it's shape is a calendar, clock, or likewise; it's stamp is bare bones data.

Whenever such stamp would contain multiple data items, a slot is used to group them as a Widget. Such Slot or Stamp or Shape is fed into a template. Which decides on it's location on the rendered page.

Imagine a date/time, to be rendered as a calendar selector and a (digital clock) time selector:
* date has the shape calendar and is stamped with the current date,
* time has the shape of a digital clock and is stamped with the current time,
* the calendar and the digital clock, aka their stamped versions, are grouped within a slot, be it a form slot or just a tiny counting slot,
* the html of the slot is fed into a templet that decides the location in the webpage.

The terminology is also based on Atomic Design Principles: Shape is the atomic form, Stamp is an occurrence of Shape. Seen this way, Slots are the molecules and Templets organisms. This way, Shapes and Slots are re-usable, which might be an overkill for straight apps.

The same example can be rendered by creating just two stamps and feed these into the templet, which may break their connection.
Finally, the same example could be rendered by feeding the shape into the templet accompanied by the current date and current time; the templet is now the workhorse. And off course, the complete shape could be hard-wired in the template, which obsoletes Shape.

And to complicate the design and usage, Slots have Stamps too. In fact, all Properties, Attributes and Slots do use a Shape and can be Stamped with data. Think about it: get a Shape and Stamp it with Data; get a Slot and Stamp it with Data - Stamps - or - Shapes.

A Shape may supply the data to Stamp it with; same goes for the Slot.

Implementation

Graph components feature a Face class for drawing (rendering): Canvas, Vertex, Edge, Planar.
The Lexicon class contains metadata on the graph component elements: Attributes, Properties and Slots. See also attributes vs properties
Lexicon also functions as a factory that creates classes to handle these elements. Those sub-classes read a manifest (included file) that defines the respective Shapes.

  • Manifests are different for view-edit-list-count modes.
  • Attributeshapes are identified by AttributeID,
  • Propertyshapes are identified by a string, either a Propertyname either a user defined key used in the app.
  • Stamps are implemented by a map class, containing the resulting text (a snippet) and additional template variables. The map is passed around to collect these parameters.

Shapes of Attributes and/or Properties are in effect small snippets, either a one-liner text or a reference to a Slot.
A Slotshape references a closure function (included file) that delivers a (complex) text.

The Stamp is fed into the Templet class. The snippet is parsed and the Templet object is returned for further processing.

Lexicon and its sub-classes are used in the Face classes when rendering.

Examples.

$lexicon->addAttributes($mode);
$lexicon->addProperties($mode);
$lexicon->addSlots($mode);

$attributes->getShape(....);
$attributes->getStamp(....);

Roadmap

  • Migrate Manifests into database
  • Create a closure database