EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.

EFRONT V4EXTENSIONS ARCHITECTURE

The goal

To offer more flexibility to 3rd 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.,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

Security

Events list

page_startup Is called before a page starts

page_shutdown Is called before the page dies