diff --git a/index.md b/index.md index 8e2a4d3..8ac3725 100644 --- a/index.md +++ b/index.md @@ -35,15 +35,16 @@ The sponsor is responsible for managing the review stage and votes. ### Pre-Draft -| Num | Title | Editor | Sponsor | -|:---:|--------------------------------|----------------------------------|-------------------| -| N/A | [Content Elements][contentelements] | Niels Braczek | N/A | -| N/A | [Authorisation Service][authorisation] | Niels Braczek | N/A | -| N/A | [Joomla Command Line][joomla-cli] | Roland Dalmulder | N/A | -| N/A | [Mobile App][mobile-app] | Elisa Foltyn | N/A | -| N/A | [Simplify Admin Views*][simplify-admin] | Elisa Foltyn | N/A | -| N/A | [Simplify Admin Views*][simplify-admin2] | Astrid Günther | N/A | -| N/A | [Composer support][composer] | Astrid Günther | N/A | +| Num | Title | Editor | Sponsor | +|:---:|------------------------------------------------|---------------------------------------------------------|----------------------------------------------------| +| N/A | [Content Elements][contentelements] | Niels Braczek | N/A | +| N/A | [Authorisation Service][authorisation] | Niels Braczek | N/A | +| N/A | [Joomla Command Line][joomla-cli] | Roland Dalmulder | N/A | +| N/A | [Mobile App][mobile-app] | Elisa Foltyn | N/A | +| N/A | [Simplify Admin Views*][simplify-admin] | Elisa Foltyn | N/A | +| N/A | [Simplify Admin Views*][simplify-admin2] | Astrid Günther | N/A | +| N/A | [Composer support][composer] | Astrid Günther | N/A | +| N/A | [Horizontal Components][horizontal-components] | Herman Peeren | Niels Braczek | *) Two different proposals on the same target, need to be merged @@ -83,3 +84,4 @@ _**Legend:** A = Accepted | D = Draft | P = Pre-Draft | R = Review | X = Depreca [form-admin]: https://github.com/joomla/rfc/pull/31 [simple-cck]: https://github.com/joomla/rfc/pull/26 [append-form]: https://github.com/joomla/rfc/pull/18 +[horizontal-components]: https://github.com/joomla/rfc/pull/39 diff --git a/proposed/horizontal-components-meta.md b/proposed/horizontal-components-meta.md new file mode 100644 index 0000000..61119b3 --- /dev/null +++ b/proposed/horizontal-components-meta.md @@ -0,0 +1,109 @@ +# Horizontal Components Meta Document + +## 1. Summary + +**Horizontal Components**, within the context of software architecture and design, refer to modular parts of a system +that provide shared services or functionality across different areas of that system. Unlike vertical components, which +are designed to address specific business requirements or user stories from top to bottom, horizontal components are +focused on common capabilities that can be utilized by multiple verticals or layers within the application. This +approach helps in reducing redundancy, improving maintainability, and ensuring consistency across the application. + +This specification seeks to address the critical issue of code entanglement within our Content Management +System (CMS), particularly focusing on features such as Tags, Workflow, Access Control Lists (ACL), Custom Fields, and +others that are currently tightly coupled with the core codebase. + +## 2. Why Bother? + +The entanglement of key features within the CMS codebase presents significant challenges to the system's +maintainability, scalability, and flexibility. The current state not only makes it difficult to introduce new features +or modify existing ones but also increases the risk of bugs and complicates the debugging process. By addressing this +issue, we aim to achieve several critical objectives: + +* **Enhance Maintainability**: Reducing code entanglement will make the system easier to understand, modify, and extend. + This is crucial for the long-term sustainability of the CMS, as it reduces the effort required to implement new + features or update existing ones. + +* **Improve Scalability**: A modular architecture allows for the system to be scaled more easily. Components can be + developed, tested, and deployed independently, facilitating a more agile development process and enabling the system + to adapt to changing requirements. + +* **Increase Flexibility**: By adopting orthogonal components, we can create a more flexible architecture that allows + for the easy integration of new technologies and methodologies. This flexibility is key to staying competitive and + meeting the evolving needs of our users. + +* **Reduce Technical Debt**: Moving away from "poor man's composition" and towards a cleaner, more structured approach + to code organization will significantly reduce technical debt, making our CMS more robust and reliable. + +* **Foster Innovation**: By simplifying the process of modifying and extending the CMS, we can more easily explore new + ideas and innovations, ultimately leading to a better product for our users. + +## 3. Scope + +A few key characteristics of **Horizontal Components** include: + +* **Reusability**: They are designed to be used in various parts of the application, making them reusable components. + This reduces the need for duplicate code, thereby simplifying maintenance and updates. + +* **Cross-functional**: Horizontal components typically provide functionality that is not specific to any single feature + or domain but is required across several different parts of an application. Examples include authentication, logging, + tagging, and message handling services. + +* **Decoupling**: By abstracting common functionality into horizontal components, applications can achieve a higher + degree of decoupling between different parts of the system. This enhances modularity and allows for more flexible + development and deployment strategies. + +* **Scalability**: Horizontal components can help in scaling the application more efficiently. Since they handle shared + services, optimizing these components for performance and scalability can benefit the entire application. + +In essence, horizontal components are foundational elements that offer common services or functionality to various parts +of an application, enabling a more modular, maintainable, and scalable architecture. + +### 3.1 Goals + +This specification aims to provide a detailed framework for the development, implementation, and integration of +horizontal components within the system, ensuring they are scalable, maintainable, and effectively reduce redundancy +across the application. It seeks to establish best practices, design patterns, and technical guidelines that will +facilitate the creation of reusable, cross-functional modules, thereby enhancing the system's overall architecture and +operational efficiency. + +### 3.2 Non-Goals + +This specification does not specifically target performance optimization or security enhancements. Such improvements may +be considered in future initiatives. + +Although the improvement of Horizontal Components may indirectly benefit the overall architecture, redesigning or +refactoring vertical components or business-specific modules is not a part of this specification. + +It is understood that some level of dependency is necessary for the functioning of the CMS. Thus, completely eliminating +all dependencies is not a realistic or intended outcome. + +## 4. Approaches + +## 5. Design Decisions + +## 6. People + +### 6.1 Editor(s) + +* Herman Peeren, + +### 6.2 Sponsors + +* Niels Braczek, + +### 6.3 Contributors + +* N/A + +## 7. Votes + +* **Entrance Vote:** _(not yet taken)_ +* **Acceptance Vote:** _(not yet taken)_ + +## 8. Relevant Links + +_**Note:** Order descending chronologically._ + +## 9. Errata + +... diff --git a/proposed/horizontal-components.md b/proposed/horizontal-components.md new file mode 100644 index 0000000..a6239be --- /dev/null +++ b/proposed/horizontal-components.md @@ -0,0 +1,19 @@ +# Horizontal Components + +This specification defines the general architecture of Horizontal Components. +Horizontal Components provide functionality to all other (vertical) components in Joomla!. + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC 2119][]. + +[RFC 2119]: http://tools.ietf.org/html/rfc2119 + +### References + +- [RFC 2119][]: Key words for use in RFCs to Indicate Requirement Levels + +## 1. Specification + +## 2. Interfaces +