Related links
Homepage
User documentation
Uživatelská dokumentaceFI - 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
Slave object management
Work with slave objects
- What is a slave object
- Mishmash slave object example – address
- Slave object implementation
- Slave object support in views
What is a slave object
Slave object is an object that exists only as a part of another object – master object
Slave object examples
- An object that encapsulates language translation of the master object. The translation makes no sense without the translated object.
- Description of the requirement analysis.
False slave objects
The literature often uses wrong examples:
- Car wheels: A car wheel is a part of a car. That's right and physically makes no sense without a car (What to do with car wheels without a car?) However, wheels really makes sense without a car – you might sell them, they are in the stock etc. So that a car wheel is not a slave object
- Work report: Work report is always linked with some task. Although work makes no sense without task, timesheet is standalone important information about somebody activity. Timesheet could not be deleted when task becomes obsolete (simply because work is completed or canceled). When a timesheet is linked with a task it preserve the task to be deleted. Pure slave object would never block deleting of a master object.
Mishmash slave object example – address
Address is a confusing example because address is and independent object linked with some property in a real World. However, most of the systems where address is stored are not about the properties but about persons living or working somewhere. Whilst a property never change its address (except rare situations when some street is renamed), persons changes their address frequently.
Address could be understand as an independent object linked with single or more properties and all persons having seat or workplace in the properties. But it could also be managed as a slave object linked with persons or properties. In the fist case system stores only unique addresses. In the second case system could store single address many times.
The first case makes sense e. g. for systems where are registered all occupants of a single house – possibly thousands of persons with single address. In such system, persons typically never change address – when they move out of the registered property they are deleted / canceled. However event in such system there might be others addresses linked with person (permanent seat of the apartment owner that does not live in the apartment).
The second case makes sense for common CRM / address books systems. In the second case it is easy to repair address of a person – simply rewrite it. Updating person address is much complicated in the first case.
Slave object implementation
Technically there are two different types of slave objects:
- Objects linked only with one master object linked by (strong relationship). These are linked with the master object ID. They can be deleted automatically by database using the referential integrity
- Objects linked possibly with several objects types (weak relationship). These are linked with object name and object id. The relation could be managed by database only using the triggers that could delete the relation automatically. (Module authors are encouraged to use the triggers or make control on higher level of the program.)
Slave object support in views
AyMINE support weak slave objects that could be linked with pair of attributes objectName – objectID. The link pair of attributes could use different name as long as they adhere standards:
- name of the object is in the
<pair_name>Nameattribute - if is in the
<pair_name>IDattribute -
<pair_name>IDhas type objectPrincipal
Example:
"objectName":{
"type":"string","length":32,
"readonly":true, "required":true,
"default":"=obj.myObjName"
},
"objectID":{
"type":"objectPrincipal",
"readonly":true, "required":true,
"default":"=obj.ID"
},
For all weak-linked slave object server loads all fields:
- objectID – should be in the view attributes
- objectName – added by server
- objectIDDesc – master object description that could be used by detail to show it.
Let's note that objectName / objectID field names are recommended but not required. Field could have different names. However, client application support pairs of field names
Correct view definition
Don't put objectName attribute to the list of view attributes. It breaks internal logic.
For both detail and list view, only the objectID field could be placed to the list of attributes. ObjectName is loaded automatically
Detail view does not have objectName attribute but the objectName value is loaded to the data object – it is available for all operations but not placed on the page (there is only single attribute with link to other object).