Give us contact

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

AyMINE

Related links


FI - Finance Management

Object Definition

Persistent object definition

AyMINE Framework is completely object–defined system and all data and functionality is defined by the object model. The model is stored in the object definition files stored in the jsonc files. (However they are not exactly in the json / jsonc format.) The definition files are processed both by client and server. Each of them used some parts of the definition.

Object definition

Internally the jsonc document is pre–processed and converted to the pure json format and then converted to the native object format. Complete definition of the object–definition is available in the objDesc.d.ts that is part of the AyMINE Framework distribution.

This document contains implementation notes and some hints related with the object definition but neither replace nor duplicates the object definition documentation.

Object definition process

A new object in the system is defined in a few steps

  • Generally, the first is and idea – definedn and designed out of the system in the business model. (We use a model made in the ArchiMate language; several outputs are here in documentation)
  • The first object definition could be made in SQL but only in case that object uses a new table. Most of the objects are created from the generally created abstract object and new table is not created. However, if a new database table is behind the object, SQL definition of the object persistence is the first step. That's important because its is used in the next steps
  • Each object should have a back–end object definition in PHP (if the PHP back–end engine is used). PHP class is descendant of the persistent ancestor (frmPersistent but most of the modules has intermediate persistent object – e.g. tskPersistent is an abstract ancestor of all objects from the tsk module.)

Related links:

SQL persistence definition

Each object has persistent data stored in the relational database. Proper object definition in the database requires:

  • Table definition – it is recommended to use table with the same name as object has. However it is not valid for objects derived from the abstract – general object patterns.
  • View for list and details (mostly i single view for both of them)
  • Hierarchy view – if object has hierarchical structure, there shall be a view of all children that is used to control the hierarchy
  • Define object name and short description in the SQL method _getObjDesc. The object should be supported by method of the module (e.g. sysUser name and description is managed by sysGetObjDesc and sysGetObjShortDesc.)

PHP object definition

PHP class contains definition of all fields of the object. The class definition is generated automatically from the SQL database model using the script from the frm development frameworks.

PHP back–end class contains methods with the business logic. All business logic is back–end managed and the client only calls appropriate methods.

JSON object declaration

JSON Object declaration is generated by the appropriate method from the frm development framework as well. However, the framework generates only attributes, list and detail field. The complete structure of the JSONC file should be copied from pattern file or even better from a similar object.q

JSON file orchestrates the object behaviour and is described in detail further.

Object support by the client application

Apart of the the object definition, there is also mostly necessary

  • Add object name to the translation of all object names (counter file objectNames)
  • Create new counters for some object-related system types (list of counters defined for module /module-directory/model/enums.json)
  • Create translation of new object fields for each language supported by the client application
  • Create a new svg icon for object and add it to the list of module icons (/module-directory/model/inconsGeneral.json)

Object documentation

Object documentation is in several locations

  • User documentation in all system languages
  • Technical documentation (this) in English
  • Model design (ArchiMate / English) in the business model

User relations

Object model allow flexible definition of the user relations. It was developed as a universal concept but in practice is not very useful because it not effective in the right–control in the view. However, support is still in the system.

Definition of the relation:

"tableSQL": {
   "userRelations": [ 
      { "name":"responsible",
         "role":"everyone sys",
         "type":"OP",
         "multiple":"01"
      } 
   ]
},

Relation usage in list or detail:

{
   "name":"responsible",
   "type":"userRel"  // type is necessary for conversion, it fails without that
},