EFRONT V3.7  EXTENSIONS ARCHITECTURE
The goal <ul><li>To offer more flexibility to 3 rd  party users to modify eFront functionality </li></ul><ul><li>To extend...
How? <ul><li>By building on our current modules architecture </li></ul><ul><li>By using an extended version of the events ...
Events <ul><li>Events are fired on different important happening inside the system </li></ul><ul><ul><li>User registration...
Possible Events
Events_mapping <ul><li>A central function that maps events with actions </li></ul><ul><li>events_mapping  is populated fro...
Events_mapping
Example 1 <ul><li>Task: A history module that populates the history log by catching a subset of the system events </li></u...
Example 2 <ul><li>Task: A content modification module. It adds a copyright background image at each unit’s content </li></...
Example 3 <ul><li>Task: A unit-glossary merger </li></ul><ul><li>On installation the module includes a hook like: </li></u...
Example 4 <ul><li>Task: Backup eFront every Sunday </li></ul><ul><li>On installation the module includes a hook like: </li...
Example 5 <ul><li>Task: Send a generic system report every day </li></ul><ul><li>On installation the module includes a hoo...
Example 6 <ul><li>Task: How to avoid “bad-words” on forum </li></ul><ul><li>On installation the module includes a hook lik...
Modules initiate a mapping with events
eFront activity can trigger modules functions
Time events can trigger asynchronous function calls
API extensions[1] <ul><li>Our external API includes ~15 functions that represent ~0.001% of eFront functionality </li></ul...
API extensions[2] <ul><li>For this method to work we need to create a module that would initiate its own event(s) </li></u...
Considerations <ul><li>How to efficiently build on current infrastructure </li></ul><ul><li>How to make it very easy to us...
Upcoming SlideShare
Loading in …5
×

eFront V3.7 Extensions Architecture

2,000 views

Published on

discussion on upcoming changes on eFront extension architecture

Published in: Technology, Art & Photos
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,000
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

eFront V3.7 Extensions Architecture

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

×