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
Module extensions
Module could extend objects from modules in lower levels
AyMINE supports module extensions – module that is build up on a functionality of another module could extend both system functionality at the back-end level as well as front-end functionality in the application
Back-end module extensions
Event handlers
Each module could register event handler for messages generated by another module. It could implement additional functionality related with the operation from the module that raised the event.
Module events are registered to the messaging system during the module installation – operator should reinstall module if event handler are changed
Usage example
System module raises an event when a new client is created
Higher task management module registers an event handler that catches the event from the system module and creates a new area to the newly created module.
Object descendant
Higher-level module could create a descendant of the lower-level module, reuse and modify its functionality. Methods created by higher-level module will call the modified functionality.
Example
HR module overrides the module from tsk module. It creates contract object as a descendant of the tskInfItem object. the back-end class of the contract is a descendant of the ancestor tskInfItem, shares default functionality and creates a new one.
Front-end module extensions
Probably most interesting is a single module extends functionality of another module at the application level.
Each object could extend front-end of another object defining the extension in the JSONC configuration file.
Usage example
task management module defines user competencies. It creates a new tab for user with competencies. The tab is visible also in the sysUser detail because task management module extended the system user view.
The extension is made at the end of the jsonc definition of the subject competence object:
{ "about": {"version":1,"module":"tsk","name":"tskSubjectCompetence"}, "data": {
...
}, // end of views
// ****************************** tskSubjectCompetence – Extensions ******************************************
"extensions": {
// *********************** sysUser extension ****************************
// name of the extended object. Object should be from lower-level module (a module that is defined to be used by extending object)
// Extensions can never make and circular extension dependency because extending object should always be from higher level than the extended object
"sysUser":{
"extParameters":{
// Uright that used should have to load the extension. If user does not have the right, extension is no loaded for him
"uright":"tsk@tskLegal"
},
// Next part is the proper extension – it is joined with the extended object
"about":{
// It is strongly recommended used as small as possible language modules linked with the extension. Otherwise, there is high risk that the extension changed improperly name of the fields from the extend object.
"langModules":[ "tsk/langs/@/tskCommon", "tsk/langs/@/competence"]
},
"views":{
"lists":{ //sysUser.lists
"--adminAbstract":{
// New filter added to the list of compentenxies
"filters":{
"fHasCompetence":{ "type":"selectObject", "icon":"userCompetence", "active":false,
"where":"/** whereCompPerson **/", "select":"tskCompetence.list.availCompetences" }
}
}
},
"details":{ //sysUser.details
"default":{
// new tab to the default user view
"tabs":{
"competence":{ "icon":"userCompetence", "box":{
"view":"form.tskSubjectCompetence.list.subjectCompetence",
"help":"tsk/tskCompetence_SubjectCompetence"
} },
"tabActivityRec": {"icon":"activityRec", "visible":"=!obj.isNew",
"box":{ "showTitle":false, "view":"form.tskActivityRec.list.--object(objectName=sysUser)" } }
}
}
}
}
}, // end of sysUser extension
} // end of extensions
} } // edn of tskSubjectCompetence definition
Remember
Do not extend single object by several objects that are descendants. It makes mess about the validity of the definitions.
Example: tskAbstractArea makes extension of the frmAymine object. Don't extend frmAymine object by tskArea, that is descendant of the tskAbstractArea because the behaviour is unpredictable.