Structure

There are a few basic building blocks of any Cobble system:

  • Commands – a single instruction.
  • Hats – a variable.
  • Coblets – a text file of commands and text.
  • Databases – permanent (mySQL) or temporary tables of data.

A command can comprise of up to 4 components:

[title destination=source ~options]

Broadly speaking the title identifies the command to do, the source provides the data, options modify the command and the result is stored in the destination.

Special cases:

If no title is entered then the command is a ‘formats’

If no destination is entered the the result is sent straight to the ‘output’ stream.

A few single word commands have no destination, source or options e.g. [blockend]

A few multi word commands, without a destination, can cope with spaces before the ‘=’. e.g. [if not selected=v|c] executes the title ‘if not selected’, and doesn’t expect ‘selected’ to be a destination.

A hat is the basic format of a variable.  It will have 2 or more components, the minimum being a ‘vector’ identifying the database and a ‘field’ for a specific piece of data. If it is a multi record database then the value is taken from the current record, that can be set using [setrecn…]

A simple hat ^|vector.field|

A complex hat ^|vector1.vector2.field|  in this case the first database is searched for the field ‘vector2’ which will contain a _tag value for the database vector2.  The result is the field value for the record in vector2 that has the _tag contained in the current record of vector1 value of field vector2.  e.g. a party booking might contain details of the person booking it, so there will be a person database and a party database. The person database might include a field containing their postcode. So the hat ^|party.person.postcode| will look at the current record in the party database, get the _tag value of the person, then look at the person database record with that _tag and return the result of the contents of the ‘postcode’ field.

A coblet is a list of cobble commands and text.  A job consists of one or more coblets:

Each coblet has a job name, job code, title and organisation code, it may also have a job type:
job name – a name for the specific coblet
job code – a code shared by all the coblets of a single job, it must be the same as the job name of the first coblet in the job
title/comment – the text displayed in drop down menus to identify the coblet
job type – the drop down menu category which has the job within it, only needed for the first coblet in a job.

When the system is looking for a coblet by name it will look for all coblets with that job code.  If there are more than 1 then it will select in the following priority order:
a coblet with that name with the same job code and org code as the current coblet
a coblet with that name at the ‘organisation’ level (e.g. job code ‘NOJOB’ and the organisation code of the specific organisation)
a coblet with that name at the ‘system’ level (e.g. job code ‘NOJOB’ organisation code ‘system’)

So each organisation has access to it’s own coblets and any general system coblets.  But if you write a ‘job’ level coblet with the same name as a system one, the the job level coblet is used.

Databases can be permanent SQL tables or temporary ones created during a job.  The only fields expected of all databases records is a unique identifie ‘_tag, which is a non negative integer, and for SQL databases a ‘_timestamp’ (SQL Date/Time of the last time it was saved) and ‘_archive’ (0 for active and 1 for archived – generally only active records are loaded by the system).

The system keeps track of the current record of each database.