efront v3.7 extensions architecture
DESCRIPTION
discussion on upcoming changes on eFront extension architectureTRANSCRIPT
EFRONT V3.7 EXTENSIONS ARCHITECTURE
The goal
To offer more flexibility to 3rd party users to modify eFront functionality
To extend eFront through modules/plugins and not core extensions
To keep the core eFront as small as possible
To facilitate further development in a faster and robust way
To customize eFront for customers without changing the core
How?
By building on our current modules architecture By using an extended version of the events
system to catch and modify system behavior By using the experience from the notification
layer to create asynchronous events By building a lot of the new functionality as
modules By re-writing current functionality as modules
(depending on the advantages it offers and time needed)
By simplifying the modules creation process
Events
Events are fired on different important happening inside the system User registration Lesson acquisition from a user Lesson completion …
We can extend this event system to include content fired events Unit content shown Right sidebar shown Footer shown Header shown …
The number of events we track will be increased through time BUT how it is treated will be generic
Each event has a unique name (e.g “user_registration”)
Possible Events
Events_mapping
A central function that maps events with actions events_mapping is populated from modules
during their installation The events mappings keeps a vector with
elements of the type: (event, module->function) For any event there might be several different
functions to call initiated from different modules An event can be triggered through eFront
usage, from the API or at specific dates
Events_mapping
Example 1
Task: A history module that populates the history log by catching a subset of the system events
On installation the module includes hooks for the events we want to retain: module->map(“user_registration”, module->user_registration()) module->map(“lesson_completion”, module->lesson_completion())
Whenever an event is fired: eFront will call the events_mapping function Events_mapping will discover the relative mappings and
will call when applicable the related functions: module->user_registration() module->lesson_completion()
some environment variables should be passed to these functions either as parameters or via global variables. This remains to be specified.
Example 2
Task: A content modification module. It adds a copyright background image at each unit’s content
On installation the module includes a hook like: module->map(“unit_shown”, module->unit_shown()) When a user tries to see a unit, the content of the unit is
passed to the module->unit_shown() function where it is modified and is returned to the system
Example 3
Task: A unit-glossary merger On installation the module includes a
hook like: module->map(“unit_shown”, module->unit_shown()) When a user tries to see a unit, the content of the unit is
passed to the module->unit_shown() function where it is modified to include the popup functionality for glossary items and is returned to the system
Example 4
Task: Backup eFront every Sunday On installation the module includes a hook
like: module->map(“asychronous_(timestamp)”, module->backup()) The timestamp is set from the current time until the first Sunday We check with asychronous calls on events_mapping the
timestamp until they are met. The module->backup procedure makes a backup, delete the
mapped event and creates a new one for the next Sunday. The module is responsible to check if the action was called at a
reasonable moment to make its designed action (in case for example that somehow it was considerably delayed due to server overhead)
Example 5
Task: Send a generic system report every day On installation the module includes a hook like:
module->map(“asynchronous_(timestamp)”, module->report()) The timestamp is set from the current time until the next day We check with asynchronous calls on events_mapping the timestamp
until its time has come. The module->report function creates and sends the report to a few
users it specifies (e.g, admins). It also deletes the old event and creates a new one with a new timestamp.
Again, the module is responsible to check if the action was called at a reasonable moment to make its designed action (in case for example that somehow it was considerably delayed due to server overhead)
Example 6
Task: How to avoid “bad-words” on forum
On installation the module includes a hook like: module->map(“forum_post_creation”, module-
>modify_post()) When a post is created it passes from the modify_post()
function which checks and modify its content depending on a user-created list of bad-words
This module needs also an administration interface to manage the “bad words” list
Modules initiate a mapping with events
eFront activity can trigger modules functions
Time events can trigger asynchronous function calls
API extensions[1]
Our external API includes ~15 functions that represent ~0.001% of eFront functionality
One way to remedy this situation is to extend the API with new functionality Which will increase eFront’s core size considerably
Another way to do it is to build a gateway between the API and modules through the event system The benefit is that the module is not part of the
core Other users can create additional modules to
communicate with the API and do various tasks
API extensions[2]
For this method to work we need to create a module that would initiate its own event(s) E.g module->map(“api_logout”,module->logout())
The only way for this event to be called is through the API E.g.,http://efront/api.php?
action=api_logout&token=IQwwIuvXlLbwjjNXNf7XHMJh2DfBEe&login=john
For a non-identified action the API will: Check the token Call the events_mapping to see if there are
modules that want to activate this event
Considerations
How to efficiently build on current infrastructure
How to make it very easy to use How to make it as generic as possible How to enforce new functionality based on
this infrastructure from the development team We need to publish the system API in a more
systematic way What about security
E.g, Modules should be able to delete their own actions only?