Architecture plans
From Cloudrexx Development Wiki
This page collects ideas and concepts for problems or features.
Generic
- Keep and make differences between modes as small as possible.
- Drop as much component code as possible by generalizing it.
- Drop remaining globals.
- Drop remaining constants.
- Make multiple instances of Cx work in parallel.
- Create a common Repository class, use it as a default and force it as a superclass for all repos.
- Minimize non-codebaseable files as much as possible.
- Cleanup Cx class to make it way smaller.
- Cleanup FileSystem implementation and move default folder definitions from Cx class.
- Introduce background jobs (draft exists).
Component framework
- Implement Component framework v2.
- Try to control every aspect of the interface between the core system and components.
- Drop LegacyComponentHandler.
- Find a better solution for cases like "Logout" or "Media1-4".
- Make the terms installing/uninstalling and activating/deactivating clearer
- Make installing/uninstalling and activating/deactivating easier
Codebase
- Move as many components as possible to their own repository.
- Drop all files that can be re-created or that contain duplicate info.
- Proxies can be generated on install/deploy.
- The structure of Doctrine entities should not be in installer/data/contrexx_dump_structure.sql but generated by Doctrine on install/deploy.
Localization
- Let each component load its own language data and provide it as $this->lang.
- Move language variables to YAML files.
- Drop language variable prefixes like "TXT_", "MODULE_<moduleName>_" etc. Maybe introduce some kind of grouping instead.
- Create a language file for all all modes (maybe even only create one per component and use some kind of grouping for mode differenciation).
Caching
- Make components no longer directly parse code for frontend (maybe as a new component framework version). Instead all interactive elements are done by JavaScript via /api/. This allows to pre-render all frontend views. This way the frontend is simply a set of HTML files (on an object storage?). If an action is triggered some of the files may get re-rendered.
- This would behave similar to always using the "Cache only" mode.
- If components do their interactive and user-based stuff via JavaScript this would not be very far away!
Backend
- Make backend work the same way as frontend (except the caching part stated above):
- Parse a template
- Parse a normal navigation, add backend areas to another root node