[RAD][HttpKernel] Create a MicroBundle base class #19596
Conversation
|
Can we make route definitions available? |
|
@ro0NL you mean configuring them ? |
|
@ro0NL the kernel is the root of the project, a bundle isn't. |
|
Understand, im talking about registering (mounting) |
|
This is possible in the micro kernel trait because the kernel is also a service but bundles aren't and i don't think they should be. |
|
As usual? // AppKernel::loadRoutes
$bundleRoutes = $loader->import('bundle:SomeBundle:getRoutes', 'service'); // getRoutes to clarify
$bundleRoutes->addPrefix('/some-bundle');I understand this is not as easy (kernel is a service like you mentioned). However for me, having the kernel as a service is just as weird as having a bundle as a service. Hence i want to propose separating this (kernel/bundle in the ecosystem vs. kernel/bundle as a service). |
|
@ro0NL ok got it, you would like to be able to use the bundle class as a resource. |
|
@ro0NL Does this bundle solve your use-case https://github.com/rollerworks/RouteAutowiringBundle? Edit. Hmm, you want to define routes as a service completely? It should be possible, but you would have to register the Bundle class as a service which seems like a terrible idea 😉 Or you need to create a complete route service definition, which is not easy I know of experience 💀 The main advantage of MicroBundle I see is the removal is Extension class. |
|
I guess for now i would workaround using the kernel as a service, which couples perhaps better anyway. // SomeBundle
public function getRoutes() {
return new RouteCollection(/*...*/);
}
// Kernel
public function loadRoutes(LoaderInterface $loader) {
$bundleRoutes = $loader->import('kernel:getSomeBundleRoutes', 'service');
$bundleRoutes->addPrefix('/some-bundle');
}
public function getSomeBundleRoutes() {
return $this->getBundle('Some')->getRoutes();
}Im not even sure it's supported though... importing routes from a service? |
| * | ||
| * @author 8000 Guilhem N. <egetick@gmail.com> | ||
| */ | ||
| abstract class MicroBundle extends Bundle implements ExtensionInterface, ConfigurationExtensionInterface, ConfigurationInterface |
There was a problem hiding this comment.
Not sure this needs to be a ConfigurationInterface.. we can eventually just call Processor::process...
Instead of that, implementing PrependExtensionInterface could be useful.
There was a problem hiding this comment.
Yes indeed i didn't know this method. I'll change that asap, thanks :)
There was a problem hiding this comment.
After all I don't think we should do that. ConfigurationExtensionInterface is used in commands such as ConfigDebugCommand and ConfigDumpReferenceCommand (should be at least, they won't work if the extension doesn't implement this interface).
And as ConfigurationExtensionInterface returns an instance of ConfigurationInterface, the MicroBundle must be an instance of ConfigurationInterface.
About PrependExtensionInterface it will only allow people to not implement the interface and it won't be used most of the time so I don't see any benefits.
There was a problem hiding this comment.
And what about CompilerPassInterface?
There was a problem hiding this comment.
@hason this interface is already easy to implement (no need of code to make it work on a bundle).
|
Would such feature be accepted? |
|
Imo it should be, as it's the missing part of the micro kernel right now. |
|
I don't really understand why this is useful in the context of a micro-*. The application using the MicroKernelTrait should probably be bundle-less. What's the benefit or introducing a Bundle in such cases? |
|
@fabpot that's useful for tests for the micro kernel but it is mostly useful for most small bundles that doesn't need a complex structure. |
|
Sorry, I wasn't clear in my previous comment. I'm not saying that this is not simpler that the default Bundle class; I just think you don't need a bundle at all. |
|
@fabpot i understand but i don't think micro apps are the biggest target here. |
|
I think that the extension system should never be used for anything but Open-Source/shared bundles. In which case, there is no need for something simpler. In any case, naming it like MicroKernel as one might think that there are related, but they are not. |
|
@fabpot why wouldn't we need something simpler? An extension may only contain services loading with maybe a few configuration parameters to manage and in this case it looks overkill to have 3 classes to do that. |
Disagree, i truly consider a micro app built from simple bundles.
Separation of concerns and reuseability.
They are :) In the sense that a kernel can load bundles. However naming it micro could cause users to think it's required to have micro bundles, when using a micro kernel. Which indeed is not the case. Maybe we can do better naming... edit: |
@Ener-Getick i think this is not truly compatible with Bundle::getNamespace, perhaps it works.. but the intention is different. What about not implementing ExtensionInterface, but rather return a generic/callback extension from MicroBundle::getContainerExtension. WDYT?
There was a problem hiding this comment.
Indeed you're right... I have to find some time to rework that.
There was a problem hiding this comment.
Done, sorry for the delay
This PR introduces a new class:
MicroBundle.It is a all-in-one class replacing the usual
Bundle-Extension-Configurationscheme by a simple interface that is enough for many app bundles:This api is strongly inspired from the
Bundleclass of theKnpRadBundle.