EFRONT V4 EXTENSIONS ARCHITECTURE

The goal  To offer more flexibility to 3 rd party users to modify eFront functionality  To further 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  User login  …  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 they are treated will be generic  Each event has a unique name (e.g “user_registration”)  Events cannot be disabled  It should be REALLY easy to add new events (we will do so all the time)

Events vs Logs  Events cannot be disabled  Logging can be disabled depending on our needs  Logging saves in database a portion of Events  Logging can and should be implemented as a system plugin

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., uvXlLbwjjNXNf7XHMJh2DfBEe&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  Security

Events list  page_startup  Is called before a page starts  page_shutdown  Is called before the page dies