Related links
Sales & Asset management
Sales related services
Description of a part of the AM module - sales partFI - Finance Management
Framework Core functionality
- AyMINE Framework Server
- frmFrm – provided functionality
- System Rights
- System messaging
- AyMINE Business – Price calculation
- Strings and translations
- Export collection of objects
- AyMINE Framework management FAQ
- The AyMINE licence model
- AyMINE On-premise
- System events
- Mutli-client architecture
- Import collection of objects
- User sessions
- Default server methods
- Client-defined object attributes
- Common Libraries
Module - support for management
Libraries & Lincences
Mobile & Web Application
- Runtime debugging
- System console
- AyMINE Application
- In-line table edit support
- Object scripting API – object lang
- Application object structure
- Multilingual support
- View of a single object – detail
- Is using EVAL / feval method risky?
- Included library – String operations
- Cliplink
- Object API – object <g>
- API – Data object
- Object scripting API – object User
- Object view definition
- Framework support for Drag & Drop
- Common libraries
- Multiple-object update implementation
- fClip & fCliplist
- Offline persistent objects
- Mobile application
HR - Human Resources
System Management (part of framework)
Task, Project, Quality
Task & Task pattern
CMS - Content Management & Web API services
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:
- For overview of all architecture layers visit the introduction page
- Usage of the object definition by the application
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
},