Concrete 9.0 Release Candidate 2 Now Available!

Issue [v9.0.0rc3] Whoops right pane crops error line off top of screen · Issue #9745 · concrete5/concrete5 · GitHub

@andrew I don’t fully agree with you when it comes to using $app->make() not being useful.

Without it you’re not taking advantage of Laravel’s container. I built several packages extending on Concrete CMS in ways that were only possible because the classes I was building on were instantiated using $app->make() and I also found myself unable to do something because the core was using new ClassName() and it was impossible to override that in any way.

1 Like

@mnakalay That’s true – and that’s certainly something we’ve taken advantage of in the past – but I think at this point I would argue that that’s really more a side effect of the container architecture than a feature that should be actively used. Certainly in the past I’ve been all over trying to use these types of approaches for extension, but I think at this point I’d argue that if you’re trying to extend a class in some way, it should be built into the architecture in a more dependable way, like a driver-based approach, or some other method of extension - than just passing a class at runtime.

The exception to this, of course, is if interfaces are actually type hinted within a particular class. Then it’s kind of generally accepted that the underlying class doesn’t know anything more about the class it’s working with than the features of that particular interface, and as long as your custom class implements the interface properly this is a good use of the container.

tldr: I think the IoC container is best left to making it easier to test classes, and forcing developers to write less code or repeat less code in order to instantiate classes. But if a particular class or extension pattern requires you to use the IoC container, you’re doing something wrong.

(With that being said, I’m sure there’s many examples of us doing exactly this within the core)

@andrew Thank you for your very well explained answer. I agree with everything you said except the very last sentence.

Unless you are going to start building the core around every idea I might have for a new package :joy: and make every aspect of it extendable one way or another, I’m still going to have to rely on the container to hack my way around stuff. And I don’t think that’s doing something wrong. That’s using what’s available.

Example: I have a package in the marketplace that lets users install plugins for CKeditor. I built it several versions before you included a way to add plugin-specific configuration for CKeditor. To allow users to still use custom configuration I had no choice but to use the container.

Other example: I built a package to let users install packages directly from Github. That’s not a package for command line users, it’s for everyday users that might be using Community Store or other packages from Github. I wanted to able to show available updates and let users update the packages from the normal Core package install/update dashboard page. Because you instantiate certain classes using new instead of the container there was no way to do that. I had to use a crazy hack to be able to do that. Granted this example was more about wanting to do it the hard way but it could have been straightforward with the container.

Will there be an rc4 with Atomik for testing? When?

Yes – I’ve just released RC4 with Atomik integrated in!

We’ll be doing another release candidate soon with more bug fixes, this latest one is mostly just Atomik.