[#38239] - [RFC] Removing \Joomla\CMS\Factory is premature with the current architecture
- Closed
- 22 Nov 2022
- Medium
- Build: 4.2-dev
- # 38239
This is in continuation with a conversation we had with @laoneo in the comments of an unrelated PR where he indicated that the Joomla project (or at the very least he personally) is planning on removing the \Joomla\CMS\Factory from Joomla 5.
In my opinion this decision is extremely premature and would prevent developers from creating meaningful software for Joomla.
I put my code where my mouth is so I sat down and tried to convert a VERY simple component as far Joomla integration goes, Akeeba Backup, to use pure dependency injection. I have bumped into some stone walls with the current architecture.
Form fields do not have access to the application object. This means that I do not have access to the session, nor can I boot my component to get access to my models. This is a show-stopper. There is no workaround. To give you some perspective, this means that my layouts used to render the field cannot add static media files (CSS, JS, etc) as I cannot access the WebAssetManager through the Document object since the Document object can only be accessed through the Application object which I do not have access to. Derp!
The only solution would be to keep Factory::getApplication() or otherwise provide a globally accessible instance of the application. In fact this would solve the other problems below by making the extension object provide access to the DI Container since Joomla insists on using it as a bloody service locator BUT does not allow developers to access the damn object, instead demanding that they pass objects around like it's the early '00s all over again!
The MVCFactory class is hardcoded and cannot be overridden in the MVCFactory service provider. As a result I am only allowed to create controllers and models with the services Joomla knows about and nothing else. If I create services for my backup engine, my automated log analyser etc I cannot access them as my controllers and models do not have access to the container, nor can I override the createController / createModel methods of the MVCFactory to inject the objects returned by these services if my objects implement a custom interface.
What I have to do is truly evil and a major step down in component architecture (all objects become God Objects to an extent which is even more evil than having JUST THE ONE God Object). First I need to override getDispatcher in my extension object to inject these objects to the Dispatcher, even though it should not know anything about them. Then I have to override my Dispatcher to inject these objects to my controllers (when neither object needs to know about what I am injecting; HORROR SHOW!) and override getModel in my controllers to finally inject these objects to the models. Yikes!
THIS IS NOT HOW DI CONTAINERS WORK TO BEGIN WITH! Normally we give a class to the DI Container and get an object with the dependencies injected. There's a buildObject which is never used, but I'll get to that.
Static helpers can no longer work without some really bad architecture. I have a simple helper which can save component parameters, something Joomla cannot do. It only requires access to the database object. Up until now I was doing Factory::getDbo().
Without the factory I need to create a static setDatabase() method in it (and every other static helper) and make really damn sure I have injected the database object before I call any of the helper's other methods. The only conceivable way to do that without risking impossible to debug issues is to do that... in my service provider, right before I return my component extension object. Whelp.
Sure, we could convert all of these into non-static helpers. However, this takes us back to the problem that I still need to initialise these helper objects which is error-prone because Joomla is playing with its DIC as if it's a service locator instead of letting me use it to instantiate objects with dependencies magically injected. So what was a one liner insurance against bugs has now become a major source of hard to debug issues.
You can no longer instantiate users to check their permissions. Instantiating a user requires access to the user factory. The only way to currently do that is going through Factory::getContainer(). I have to do the stupid thing I described above where I inject this factory to the Dispatcher to inject it to the Controller to inject it to the Model. Jesus wept!
This is what I got the first two hours. One problem is a show-stopper, the others are just abysmal architecture which will cause a gazillion bugs.
Ironically, the best workaround I could find to all of these issues is create my own static helper class (basically, my own CMS Factory object) which is populated by the service provider which, get this, has full access to the bloody container I cannot access anywhere else! Given how chaotic all other alternatives are, you can bet this is what 3PDs will do if they have to deal with a version of Joomla which does not have the CMS Factory. At least those which stick with Joomla instead of leaving for presumably greener pastures.
If you want to remove the CMS Factory from Joomla 5 you need to stop playing with its DIC and use it as a real DI Container. There's already buildObject in it which is not used anywhere and it's also not usable as-is (it assumes a pretty much Singleton implementation of all instantiated objects). But it's a good start. Refactoring that to have its guts as createObject returning transient objects and passing the DIC around (instead of arbitrarily selected objects) would help.
Otherwise we need a way to have each component define its own MVCFactory much like we let it define its own Dispatcher so the developer can choose to inject custom dependencies based on their own interfaces instead of being limited to what Joomla's MVCFactory wants to do. The way this is coded right now is not conducive to overriding as it requires overriding both the MVCFactory itself AND its provider, the latter being CMS version specific which means that we 3PDs would have to maintain a different version of our software for each and every Joomla version — this is impossible and yes, we do have many clients who are still using Joomla 4.0 because an extension or another is still not Joomla 4.1 ready.
Finally, form fields MUST have access to the application and layouts must definitely have the same access as well. Anything else makes Joomla's component and plugin configuration interfaces useless, requiring us 3PDs to reinvent the wheel to do anything slightly more complicated than the absolutely trivial — something we didn't have to do since Joomla 1.0, mind you!
Tagging @nibra @HLeithner @wilsonge
joomla-cms-bot
- | Labels |
Added:
?
No Code Attached Yet
|
||
but joomla 5 is still scheduled for public release in 407 days
but joomla 5 is still scheduled for public release in 407 days
Joomla releases are time scheduled since 4.0 there is no plan to change this. If features (or deprecations) are not ready for the release they will be shipped with the next possible version.
The minimum expected b/c changes for Joomla 5 will be PHP/MySQL/Postgresql version and used 3rd party dependencies.
@HLeithner Yup, understood. I just wanted to give some feedback from the point of view of a 3PD since we're using Joomla a bit differently than the core (we don't have the benefit of refactoring code to suit us — that's why MFA in the core is so much darn simpler than as a system plugin, LOL!). I wanted to give you ammo in case it comes to a department meeting. I don't have any decision making power but I did have two hours to kill and I thought, hey, let's try and see how easy it is or not.
Regarding the architecture, I can help you as much as I can but there are some design compromises that happened without my input. I know that @wilsonge is also not very happy with the way the DIC is used but we had to start somewhere and maintain some modicum of b/c with J3, so there's that.
About Joomla 5, I agree that having a timed release is a good thing — and I will also add unfortunately as a big and important qualifier. Joomla 3.10 and 3.0 are very different products but all that people saw was "JoOmLa Is StUcK iN tHe SaMe VeRsIoN, wOrDpReSs PuBlIsHeD tWo MaJoR vErSiOnS aLrEaDy". The truth was that Joomla had at least three major architectural changes in that time, WordPress had one. As much as I hate it, we need timed major versions for marketing reasons and to have a meaningful legacy management. Damned if you do, damned if you don't, Brian disagrees but c'est la vie ;)
As much as I hate it, we need timed major versions for marketing reasons
Thats precisely why I am not a fan. Its not easy to market something to the general public when there are no features to market.
@nikosdion i fully agree with you.
Actually the way that Joomla is moving on (in its code) is causing its continued downfall year after year and is causing developers to leave the ship. There are fewer and fewer extensions as time goes by and fewer and fewer people investing in Joomla and making a good business.
Joomla 4, after almost 1 year since the first release, has failed. There are still a lot of developers that have not updated their extensions or have updated them with minimal differences and poor results just to make extensions run on J4, while Joomla still continues to lose market in favour of Wordpress.
It would have been better to focus on the CMS for users instead than the CMS for developers... nobody is interested if Joomla uses a DI container or a Factory, on the contrary developers are continuosly forced to rewrite and update their extensions making them upset.
But sadly, Joomla is done by developers with the mentality of developers. This is why the destiny of Joomla is sealed in a few years more.
Developers that make business with Joomla extensions like me, probably should start to migrate more and more to Wordpress that, i know, it has a bad and old fashioned code, but that never changes. In several years and across 3 major versions, i never had to update my Wordpress plugins. This is what make developers happy and confident in what they do.
@nikosdion Thank you for your insights! We'll definitely keep that in mind.
[OT] @joeforjoomla
This is why the destiny of Joomla is sealed in a few years more. Developers [...] probably should start to migrate more and more to Wordpress that, i know, it has a bad and old fashioned code, but that never changes
Quite the opposite. Joomla will also work with PHP 9 and PHP 10 and will be able to use the techniques that will then be available. With WordPress, it is doubtful whether it will survive the EOL of PHP 8. But by then WP will probably only be available as SaaS written in JavaScript anyway..
@nibra You're welcome!
@joeforjoomla I am afraid I will agree with @nibra here and not out of fanboyism but because this is exactly what Mullenweg said in WordCamp Europe 2017. When he laid out his plans for the future it was that WordPress would be a hosted solution and its plugins JavaScript SaaS.
On top of that, I've already been making plugins for WP since 2014 — that's 8 years and 2 months already. WP's code base cannot support anything near as complex as the simplest Joomla component. Take a look at the vast amount of hacks and workarounds they had to do for WooCommerce, not to mention that it doesn't actually work without a WooCommerce-specific theme. That should tell you everything. Not to mention that the WP market is oversaturated, there's much less money in it than Joomla and the quality of clients you get is not very lovely. I don't think you're doing anyone a service by suggesting they spend 20x the development time for a CMS that will give them 60% to 90% less income; if anything, you're pushing people to their professional demise.
Regarding the decline in income, let's not forget that our extensions do not exist in a vacuum. First of all, by 2016 we were on year 4 of Joomla 3 and there was officially no end in sight. Sure, Joomla 3.4 and later had little to do with Joomla 3.0 but people didn't know. They saw six year old Bootstrap 2 used by default and a major version stuck for years so they started getting antsy and going to WP. By the time we started to see people coming back to Joomla in anticipation of Joomla 4 and business picking up we had a global pandemic which totally messed up the global economy. Just about the time the global economy was picking up again we got a war in Ukraine which decimated the EU economy, the traditional strong market of Joomla extensions. These are external factors and I see that they have had the same impact across both Joomla and WordPress products (my data is solid as I have a healthy overlap between product lines, with clients who use both CMS).
Also, a little point, if you want. You complain about the business being slow but you live in an economy with 4% unemployment rate and well-paying tech jobs in great demand. I live in an economy with 20% unemployment rate and shit paying tech jobs (US$17,000 per year before taxes for 80-hour weeks). I think that if someone should complain about the business downturn due to global events that should be me, not you. Please check your entitlement.
It would have been better to focus on the CMS for users instead than the CMS for developers... nobody is interested if Joomla uses a DI container or a Factory, on the contrary developers are continuosly forced to rewrite and update their extensions making them upset.
This^
If y'all don't care about architecture at all and don't see its utility try reimplementing any more than trivial component on WordPress which has ZERO architecture. Then come back and tell me if architecture matters.
The reason you can write complex components in Joomla is that you have things like a database abstraction layer with a query builder, an MVC framework, routing, template and layout overrides, the ability to integrate core features (tags, fields, categories, ...) into your components and so on. WordPress has none of that. You have to write spaghetti code or reinvent MVC for every plugin, you need to write clumsy regex-based routing making sure you don't break anything else, you need to write custom themes if you need something beyond WordPress' "you don't get to display crap in the frontend if it's not a post", you have to write React.JS against an undocumented API to integrate your stuff with the block editor, you don't have overrides (you need to reinvent it yourself for every plugin) and forget about integrating core features because there are none to begin with and if you do consider blocks to be core features you're in for a nasty surprise.
So, yeah, my dudes, ARCHITECTURE REALLY DOES MATTER, ESPECIALLY FOR US THIRD PARTY DEVELOPERS! The reason you can write cost-effective code and make a living is because some people put their time, unpaid (for the most part) into Joomla's architecture. Let's show some respect and recognise that this very architecture is why we can make a living in the first place! Joomla has a lot of negatives which need to change, its architecture supremacy over the competition IS NOT one of these.
As for the global Factory (which is in fact a God Object, NOT a factory for the most part) vs Dependency Injection the reason to use the latter over the former has been explained in great detail by people far smarter than all of us here combined between 30 and 50 years ago. To begin with, something I believe all of you are keenly aware of, is that currently you cannot write real Unit Tests for your code. At best, you can kinda-sorta test parts of your Models and that's when there's no interaction with the rest of the system. If you use just the session you're in a world of pain (oh, BTW, WordPress doesn't have a session — it has forever persisting "transient" configuration objects which survive a logout, LOL!). Having Joomla finally move to dependency injection, if done right, will also come with real world mocks for all these core objects. This means that you can write Unit Tests instead of crossing your fingers and hoping for the best. Sure, you're not going to go for a full test coverage but you can definitely cover your critical code without the uncertainty that surrounds this endeavour now.
AS for rewriting your software, oh, come on! My own components were not even written using Joomla's MVC framework. They were written in FOF 3 or 4 which had a completely different concept for the persistence layer: each Model was following a Active Record pattern. I had to completely rework the logic of all Models, relearn Joomla's Form package and figure out how to write native Joomla 4 components and plugins without having any documentation and in the latter case without even having a single sample plugin. The first component I converted was Akeeba Backup which took me all of 2 months while still maintaining my existing software versions, making new releases and doing support. Two weeks of that time was me learning the new MVC and another two weeks was me converting view templates to use Bootstrap 5 instead of my own FEF framework (completely different concepts) + converting my JavaScript.
The only massive changes in how you build a Joomla component came in the Joomla 1.0 to 1.5 transition with the introduction of MVC. That was 15 years ago. Everything else was incremental. If you bother to keep track of Joomla's development you have enough ahead warning except very few but admittedly annoying cases (moving JMail to use Exceptions instead of returning false in a minor version without any ahead warning tops my list).
Again, you don't have to take my word for it. Try converting your RSForm to run in WordPress. I'm not even telling you to do that with RSFirewall because there's little to no code you can keep (been there done that with Admin Tools). And I am just telling you to convert what is the easiest extension to convert on purpose. If you try converting something that has a strong frontend that cannot be embedded in a post, like RSTickets, you will see how Joomla has saved you dozens of thousands of Euros in development time and thousands of hours in preventing support nightmares.
Let's bitch about the things which are not done right, not about the things that Joomla is doing right. Wanna bitch about changes NOT being properly communicated to 3PDs? I am with you, brother! Wanna bitch about how "Joomla's b/c promise" is a joke when there are b/c breaking changes in minor changes because "how else can you deal with legacy in the future"? Damn straight I'll support you! Wanna bitch about some changes are made with just the core in mind, without asking 3PDs or users for feedback? Hell yeah, I am here to support you! But telling me that Joomla's architecture doesn't matter? No. That's stupid.
And you liked that experience so much that you want to inflict it upon others? Idiot.
You must be fun at parties
I don't go to parties. I contribute major features to Joomla, help with its architecture and even started the Joomla 4 Working Group instead of going to Joomla's GitHub page to idly bitch about it.
Please, stick to the point. Personal attacks do not help anyone.
Hey guys, please claim down. Fact is Joomla (or better the current leadership team) doesn't want to stick in 2010 and also our contributors doesn't want to stick with a code base that look and feels like a dunghill.
We or at least me see Joomla as an important framework and CMS for the future of web development. Our competitor isn't WP or WIX (they are competitors). From my point of few (and sadly we don't have a clear direction what the joomla community wants because it's so big and different) Joomla is somewhere between a self hosted WP and Drupal. But that doesn't mean we want to leave our community behind, it's exactly the opposite. Joomla must bring our community/site builder/integrators/extension devs forward. So they are able to build any project they want and to be honest there are not many sites out there which can't be build with Joomla!. And it would be never be a bad decision to use Joomla to build a website (of course sometimes a framework would fit better but that's not the point).
So from my point of view we do something good for all of us if we build a better foundation for the future of Joomla and sadly cutting off old habits is part of this process.
so please please share the roadmap
so please please share the roadmap
We are working on it, not only to have an endless feature list (which can't be met). It took some time to have a (hopefully) realistic paper that could be achieved with the wo/men power we have.
Looking forward to it. If you need a proofreader you know how to reach me
Looking forward to it. If you need a proofreader you know how to reach me
Thanks for the offer.
I guess this can be closed now as the decision has been made not to remove it
Is there a reason this is still open?
@brianteeman I think it would make sense that @nibra or @HLeithner write a comment that the decision was made not to remove this in Joomla 5 and close this issue. Otherwise an external observer would be wondering who made which decision when and why this is closed without appearing to be resolved
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-11-22 15:55:20 |
| Closed_By | ⇒ | HLeithner |
I think that's clear with my first comment... so no \Joomla\CMS\Factory gets not removed in Joomla! 5.0, JFactory class alias will be moved to the combat plugin and maybe removed in Joomla! 6.0 doesn't mean that the Factory will be removed in 6.0 maybe some less used proxy functions but that's nothing for now.
Thanks for you input, I'm not at the point yet to answer your issue. But what I can say already, Joomla it self uses JFactory a lot (the same way as you did in your component) so it would be impossible for Joomla to remove JFactory as long as the CMS it self depends on it.
I'm personally not sure if it's even possible to remove JFactory at 5 and to be honest I wouldn't force it with a hammer. There are so many other things in J5 which can/will be removed with proper replacements in place.
As you, I also, noticed already that much more code have to be written to do the same thing in J4 as in J3 at some points. Since you know J4 is older then me (in core development), it was before my time and I still try to understand the reason why somethings are done as they are. Pretty sure I will come to you to explain me some of the design decisions.
So please be a bit patiently till I (we) have a better overview.