mbabker wrote:First, just to be clear, there is no "development team", for better or worse. The software is built and managed by a bunch of volunteers, there is no real team driving or managing its vision or development other than to make decisions on what patches are applied. That might offend some but IMO as a past leadership team member that's my perception. So you aren't going to get an answer from "someone that matters".
There is no development team, but there are development working groups, so, even if they are community driven, there's always someone, at some given time, more qualified to know first-hand what is "on the table
" regarding the development, right?
When I was talking about "someone that matters", I was referring to these community members.
mbabker wrote:Dating back to Mambo, Joomla has always acted as two separate applications; the frontend and admin. Everything at the extension level was split between them, and that design decision has still carried forward to this day. Can it be improved? Absolutely. Will it be? Truthfully, as much as I'd like to see it change, I'm also going to say I doubt it. A major structure overhaul like that will be a massive backward compatibility break; without some mighty fine explanations, users aren't gonna see the benefit and those writing extensions are going to have to be convinced to make the same changes to their code.
IMO, "both" applications aren't really separated, because you can't really take the administrator
's application, and place it somewhere else (different domain, within same server). The administrator's folder, has to always be a sub-folder of Joomla's root.
Regarding backward compatibility, I have my reservations about it breaking!!!
The correct structure is already in your deployment file (admin/site), and if the developer uses Joomla's JPath
variables for file-system navigation, and stores it's dependencies in the media
folder, then I'm not seeing the need for a single line of code change, to be honest.
On top of that, the extension is called by the core, so, you don't really need a third party to make any changes on where the extension is called from.
mbabker wrote:The entry point file in components and modules predates Joomla adopting an MVC infrastructure, but that file to this day is arguably the most powerful tool in a component developer's toolkit. It enables developers to create components that can do much more and allows them to not have to implement Joomla's MVC layer at all.
I'm just saying that the entry point doesn't make sense, not that it's purpose doesn't make sense. What I mean by this, is that if Joomla extensions are to be primarily MVC pattern extensions, then the entry point should change.
If your option
var has the value "com_mycomp
", then the entry file should be a method called "mycomp
", in a class called "MyCompController
", in a file called "mycomp.php
", in the controllers
folder of the component.
This doesn't mean, that the MyCompController
class should inherit from any of the JController
classes, or that it will implement any MVC. An entry point, is just an entry point.
mbabker wrote:The option and task query vars, while also relics of Joomla past, are how URLs get mapped to components and controllers. Without the option, Joomla can't route to a controller, and the task defaults to display, so that can be omitted for most pages (it's only needed if you're routing to an edit or save task, for example). Again, it can be improved, but you're also imposing a major compatibility break for what gain; less query vars in non-SEF URLs?
The idea not only was to simplify the extension logic, but also to simplify SEF URL creation as well. Maybe, even discard the router.php
If a Menu Item
's node, holds already the context language, component/controller and method to be called, then most of the website is already contextualized, if the controller
's method calls directly the Model
(s) and the View
to be displayed.
If you add an extra segment to the URL, you already know it's going to be some Alias
, for a specific View
Regarding compatibility issues, you can make an extension that deploys files to a "2.X" version of Joomla, and/or a "3.X" version. If there were no compatibility issues between them, you would only need one file version deployment, right???
Even after "3.X" was launched, "2.X" was still supported for a long time, so, why not make things differently in version "4.X" of Joomla, while keeping the support for version "3.X" as well?!
mbabker wrote:By default, a single model is wired up in controllers, and views. In both of those objects though, additional models can be loaded if you need them (see the getModel method in controllers). So that gripe IMO is unfounded.
That is true!
I withdraw my previous statement.
mbabker wrote:Our controllers aren't mapped one-to-one with views. So the view query var actually becomes important here; (...) The layout var lets you change the layout of the view without needing additional views (like the category views in com_content, there's default and blog layouts).
But should the end user be allowed to change it in the query string? That was my point.
I agree with your statement, that a controller
shouldn't be stuck with an "hard-coded
" view, but I think is the developer's job to decide which one to use, and not the end user.
mbabker wrote:Proper MVC wouldn't fix the routing issues in Joomla. (...) between menu routes, module configs, and other user options, that one controller may end up being called by 3 or 4 URLs with different rendering behaviors.
Can't that be seen as content replication by some Search Engines?!
One content, in a specific web-site, should only be called by a single URL, or am I seeing this wrong?
mbabker wrote:Don't take this post as me being dismissive or saying there aren't issues and everything is awesome.
Not at all. At last, someone with a good core knowledge was come out and talked about possible improvements in Joomla. I wouldn't be typing this long posts, if I also didn't care about the platform, so it's nice to get some feedback about issues it might have, even if the discussions can be just at an academic level, and might not produce any effective change...