EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify...
-
Upload
quinton-siddens -
Category
Documents
-
view
219 -
download
2
Transcript of EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify...
![Page 1: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/1.jpg)
EFRONT V4EXTENSIONS ARCHITECTURE
![Page 2: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/2.jpg)
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
![Page 3: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/3.jpg)
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
![Page 4: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/4.jpg)
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)
![Page 5: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/5.jpg)
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
![Page 6: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/6.jpg)
Possible Events
![Page 7: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/7.jpg)
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
![Page 8: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/8.jpg)
Events_mapping
![Page 9: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/9.jpg)
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.
![Page 10: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/10.jpg)
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
![Page 11: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/11.jpg)
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
![Page 12: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/12.jpg)
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)
![Page 13: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/13.jpg)
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)
![Page 14: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/14.jpg)
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
![Page 15: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/15.jpg)
Modules initiate a mapping with events
![Page 16: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/16.jpg)
eFront activity can trigger modules functions
![Page 17: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/17.jpg)
Time events can trigger asynchronous function calls
![Page 18: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/18.jpg)
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
![Page 19: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/19.jpg)
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
![Page 20: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/20.jpg)
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
![Page 21: EFRONT V4 EXTENSIONS ARCHITECTURE. The goal To offer more flexibility to 3 rd party users to modify eFront functionality To further extend eFront.](https://reader035.fdocuments.us/reader035/viewer/2022062515/56649c755503460f949287cc/html5/thumbnails/21.jpg)
Events list
page_startup Is called before a page starts
page_shutdown Is called before the page dies