-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MVC Redesign #40
base: master
Are you sure you want to change the base?
MVC Redesign #40
Conversation
How many times are we going to rewrite the MVC for Joomla - this is at least the 4th rewrite. Every time the reasoning is the same. |
The structure of the MVC has certainly improved over time. However, no one has yet taken the time to carefully think through the problem and weigh up the various possible solutions. As long as such fundamental questions are answered and decided on the basis of gut feeling, we will have to make improvements. With a thorough examination and discussion of the issue, the chances are good that we will arrive at a solution that works well in the long term and really makes life easier for developers. |
Until at last we do it right... 😅 I don't see the reasoning being the same every time. Could you be a bit more precise what you mean by that. What reasoning do you assume we have now and how is that the same in previous attempts to update our MVC? That could be interesting. It was my initiative to put this issue on our agenda again, because I see some architectural problems with the current MVC classes, that were not or only partially solved with previous attempts. So I hope we can have a good discussion about it with useful contributions. It might help Joomla a bit further. |
That is incredibly disrespectful of those people who have actually rolled up their sleeves and done the hard work to imply that they did so on a whim without any thought. I know you were part of such discussions in the past and just because they didnt go the way that you wanted them to go to simply dismiss them is very poor form. I am sure that you will be once again raising the subject of ORM for exactly the same reasons. |
Please don't assume too much, put too much salt on every word. That is not very productive for a discussion. And oh, the subject of ORM (or AR-implementations of relations between entities) will be more discussed in #41 (also my initiative to start this discussion again). If people who want these discussions (like me) can just have a discussion, that would be nice. If you think this discussion is not useful, then that is alright. But I think it is necessary to have this discussion and preferrably in the open. |
its not a great start to a discussion when you start with
Statements like that really annoy me as they at best make assumptions without knowledge and at worst well lets not go there. It seems to me that every few years the same topics are rolled out but when it comes down to it either no one is interested or isnt prepared to invest anything more than words. |
That's not what I'm doing (or at least intending). I said "carefully think through the problem and weigh up the various possible solutions", which is a conjunction. Which architectural alternatives have been investigated? Why were they rejected in favor for the current implementation? I can't find any documentation about that. However, the current implementation solves a bunch of issues, but still leaves another bunch unsolved. So we need to rethink and improve, right until there are no issues left. |
@nibra you might not be intending to be disrespectful and I am prepared to put it down to you not being a native speaker but you should know that to a native speaker like myself you didnt meet your intention. I cannot comment about lack of documentation of previous discussions. You were in them - I wasnt |
I apologize if I have inadvertently stepped on anyone's toes. |
My gut feeling is that we have (many) other pleaces we have to work on with bigger priority. But feel free to discuss it :-) |
Summary
This Request for Comments (RfC) proposes a fundamental shift in the approach to the Model-View-Controller (MVC) architecture within our system, moving from a hierarchical class structure to one that favors composition over inheritance. The motivation behind this transformation is to increase modularity, flexibility, and ease of maintenance within the application. A preliminary effort toward this goal has already been initiated through the adoption of a service locator as a form of dependency injection, indicating a move towards a more compositional architecture. This RfC aims to explore and define the next steps in completely rewriting the MVC framework to fully embrace this compositional approach. Additionally, it seeks to reevaluate the roles and interactions of the MVC components to better align with the needs of a client-server web architecture, such as that of Joomla. The objective is to discuss potential directions for the MVC classes, considering the dependencies of all features and how they might be optimally composed.
Why Bother?
The transition to a compositional MVC architecture addresses several critical challenges and opportunities within the current system design:
Increased Modularity: By defining features as independent dependencies that can be composed as needed, the system becomes more modular. This modularity facilitates easier updates and enhancements, as changes to one component can be made with minimal impact on others.
Enhanced Flexibility: Composition over inheritance provides greater flexibility in how functionality is organized and utilized within the application. It allows for more granular customization of the MVC components, enabling developers to tailor the system to specific needs without altering the core architecture.
Improved Maintainability: A compositional approach simplifies the MVC framework, making it easier to understand, debug, and maintain. This is particularly beneficial in a complex system like Joomla, where simplifying interactions between components can significantly reduce development and maintenance overhead.
Alignment with Modern Practices: Moving towards a compositional architecture aligns Joomla with current best practices in software design, particularly in the context of client-server web applications. This alignment not only enhances the system's architecture but also makes it more appealing to developers familiar with modern development methodologies.
Future-Proofing: As web technologies evolve, the flexibility provided by a compositional MVC architecture will make it easier to adapt to new trends and technologies. This ensures that the system remains relevant and capable of incorporating advancements in web development.
The proposed overhaul of the MVC architecture is a forward-looking initiative that promises to bring about significant improvements in the system's design, maintainability, and adaptability. Through this RfC, we invite contributors to engage in a comprehensive discussion about the future direction of MVC classes, laying the groundwork for a more modular, flexible, and efficient application framework.