Extensions brainstorming
From EFrontWiki
This is an internal page for brainstorming on eFront v4 (previously targeting v3.7) plugins architecture based on system events.
Contents |
[edit] Overview
[edit] The Goal
- To offer more flexibility to 3rd 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
[edit] 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
[edit] 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”)
[edit] 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
[edit] Examples
[edit] API extensions
- 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
- 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
- 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
[edit] How others are doing it
[edit] Wordpress
http://codex.wordpress.org/Writing_a_Plugin
[edit] Hooks
Many WordPress Plugins accomplish their goals by connecting to one or more WordPress Plugin "hooks". The way Plugin hooks work is that at various times while WordPress is running, WordPress checks to see if any Plugins have registered functions to run at that time, and if so, the functions are run. These functions modify the default behavior of WordPress.
For instance, before WordPress adds the title of a post to browser output, it first checks to see if any Plugin has registered a function for the "filter" hook called "the_title". If so, the title text is passed in turn through each registered function, and the final result is what is printed. So, if your Plugin needs to add some information to the printed title, it can register a "the_title" filter function.
Another example is the "action" hook called "wp_footer". Just before the end of the HTML page WordPress is generating, it checks to see whether any Plugins have registered functions for the "wp_footer" action hook, and runs them in turn.
[edit] Hook types
There are two kinds of hooks:
- Actions: Actions are the hooks that the WordPress core launches at specific points during execution, or when specific events occur. Your plugin can specify that one or more of its PHP functions are executed at these points, using the Action API.
- Filters: Filters are the hooks that WordPress launches to modify text of various types before adding it to the database or sending it to the browser screen. Your plugin can specify that one or more of its PHP functions is executed to modify specific types of text at these times, using the Filter API.
List of Wordpress hooks: http://adambrown.info/p/wp_hooks
[edit] Joomla
http://docs.joomla.org/Developers
[edit] How we are doing it
The current expanding/communication methods inside eFront are as follows:
- 1. We've got the API that offers a secure mechanism to trigger eFront functionality from other applications.
- 2. We've got the modules infrastructure that allows us to extend eFront functionality.
- 3. We've got the themes functionality (introduced in v3.6) that allows us to build and share themes.
On v3.6 we have created an events infrastructure to catch important happenings and the notifications infrastructure to trigger asynchronous events. We plan to use these tools as core ingredients for the extensions mechanism.
Today a lot of eFront functionality comes as modules (http://www.efrontlearning.net/download/modules.html). However, only a few users on the community has used this infrastructure to create something on their own.
The tricky point in this process is to build on what we already have. Especially the functionality for manipulating modules has been proven to be solid and we would prefer to retain it through this process.
Our current modules infrastructure is based on an abstract module class that needs to be extended as needed to produce visual elements or catch a few predefined events. The modules can also interact with eFront's interface to add new visual elements for different user types.
My current thoughts on the needed extensions are summarized on the following additions:
- The modules will have a "method" to get attached to an event (through an events observer). Whenever the event is fired the module will be called.
- The module will be able to initiate an asynchronous event. The asynchronous event will fire a module's method on its timing.
Example 1 Say that we need to remove a user from a lesson after 10 visits. Currently something like that cannot be done and would need core extensions. With the new extension architecture we will be able to create a plugin that is fired whenever a user in assigned to a lesson and whenever he logs in to a lesson. When the user is assigned to a lesson it will initialize a counter for that user that progressively count-down with each access. At the end of his 10 visits it will remove the specific user for the lesson.
Example 2 Say that we need to remove a user from a lesson 10 days after his first visit. Again, this is not possible today without core extensions. With the proposed extension architecture we would create a plugin that is fired whenever a user accesses the lesson. With the first access we will trigger an additional time-based event that is scheduled for 10 days after the event. The even will fire an additional method of the module that would remove the user from the lesson.
 Possible hooks/events position |
On top of the above, our current API will be expanded with a generic method to fire a standardized or custom system event. This on its own will be able to trigger other plugins. For example, you might use the API to call a custom "create X report" event that will trigger a plugin that does the job.
