Hooks

The e_components work perfectly well when it comes to the user defined modules - when we know what we are going to use and when we explicitly declare in the code we are using the particular component. However, at some point it may be useful to provide some kind of hook mechanism (like the extension points in Eclipse RCP). That kind of inversion of control could make the core framework very fast and slim and users will be able to inject those features which they really need.

Each of the hook is a place where we can inject our own function, so it is possible to customize the behavior of the core applications (eptic, eptic_fe, wpart, wparts).

For example, let's assume we have e_lang refactored (it is now a separate component). We want to customize e_cache or e_ets_cache to check if the language files changed (if so, the cached content is no more up-to-date). e_cache provides the hook point validity_check where we can add our own functions which takes two arguments (Filename and ModificationDate) and returns bool(). We can register our own validity checker, which will compare the modification dates of the language files and return a proper value.

The registration process would take place in either install/1 function or it could be moved to the new optional one (which will return a list of tuples: {Module, HookPoint}).