Introduce component architecture and menu and shortcut components
This merge request is a request for comments on the component architecture plan. The plan is:
- Each application in FreedomBox is implemented as a class called
- This class is composed of many components (
Component) each responsible for a small area of the app. Components could manage a menu item, a shortcut, Apache configuration, systemd service, firewall ports etc. This will make an App very readable as interactions between components is non-existent.
- Components are highly reusable across apps.
- Components are created during the initialization of the app and (mostly) kept for the entire life type of the app.
- App implements operations like enable, disable, is_enabled. This provides a uniform interface for performing many operations in a generic way on each app (this will simplify a lot of code).
- App's implementation is simply delegated to components.
app.enable()is nothing but
for component in app.components: component.enable(). This will eliminate most of the code we have in each app's
__init__.py. This reduction in repetition will also eliminate a source of many bugs.
- Ultimately, most of the applications will be implemented by just creating a derived
Appclass which has
__init__()in which components are added. Most other methods won't be necessary unless some custom logic for the app is needed.
- The process of creating components can be made declarative and moved to manifest file. App will simply add itself components by looking at a manifest file. This will bring us very close to adding apps without any coding.