Architecture plans

From Cloudrexx Development Wiki
Jump to: navigation, search

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