• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
eFront V3.7 Extensions Architecture
 

eFront V3.7 Extensions Architecture

on

  • 2,416 views

discussion on upcoming changes on eFront extension architecture

discussion on upcoming changes on eFront extension architecture

Statistics

Views

Total Views
2,416
Views on SlideShare
2,412
Embed Views
4

Actions

Likes
0
Downloads
26
Comments
0

1 Embed 4

http://www.slideshare.net 4

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    eFront V3.7 Extensions Architecture eFront V3.7 Extensions Architecture Presentation Transcript

    • EFRONT V3.7 EXTENSIONS ARCHITECTURE
    • The goal
      • To offer more flexibility to 3 rd 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?