Decoupling the Bundle system from HttpKernel would be handy for systems that don't need the Http stuff, but want the Bundle management. The initial work has been started over at https://github.com/symfony/symfony/pull/4819 .
Thanks, Rob On Thursday, July 12, 2012 11:06:23 AM UTC-4, Beau Simensen wrote: > > I started work on extracting Bundle from HttpKernel into a Bundle > Component <https://github.com/symfony/symfony/pull/4819> with the goal of > promoting reusability of Bundles as a packaging mechanism outside the scope > of HttpKernel applications. My main reason for extracting Bundle was > because I didn’t want to depend on an “HTTP Kernel” in my non-HTTP > application. > > I’m still very new to Symfony so I had not really paid much attention to > HttpKernel or Kernel until very recently. I started to look at it more > closely last night because I wondered if I could use *Kernel* itself and > leverage a much larger chunk of Symfony code for my project since I was > needing to do many (all?) of the same things that *Kernel* was. I was > encouraged by the following: > > *The Kernel is the heart of the Symfony system. It manages an environment > made of bundles.* > > This sounded like exactly what I was hoping for so I started digging in to > see what I'd need to do to support it. It implements KernelInterface… > awesome. Wait, why does KernelInterface extend HttpKernelInterface? D'oh. I > asked around on #symfony-dev why KernelInterface extends > HttpKernelInterface instead of being independent and got some fun > responses. Main takeaway: Kernel is in HttpKernel, so it makes sense for > Kernel to be HTTP-aware. Yes, this makes sense, but it is *not* the > answer I was hoping for. What it did was get me thinking that maybe Kernel > shouldn't be in the HttpKernel component then... > > So I spent some time this morning looking at whether or not it would be > feasible to detach Kernel from HttpKernel for the purpose of making it a > standalone component. I think it might be possible but I’m not 100% up on > all of the internals so I wanted some feedback on this before I actually > try to make it work and waste what will undoubtably be a lot of time if > there is little or no chance of this being accepted. :) > > One direction: > > - Provide a Bundle component that encapsulates the core bits of the > internals of a Bundle. (BundleInterface, abstract Bundle, etc.) > - Provide a Kernel component that is capable of creating a > HTTP-unaware application that leverages all of the Container + Bundles. > (KernelInterface, abstract Kernel, DI Extension support classes, etc.) > > Alternative: > > - Provide a Kernel component that has Kernel + Bundle stuff in it. > > The former results in two extra components versus just one which might be > considered a negative. It is more flexible though and would open up the > door for more people to use the core structure of bundles. The latter would > be less flexible but would result in code that is organized in a way that > is more simple. > > In all cases, the existing *HttpKernelInterface* and *HttpKernel* would > stay the same. *KernelInterface* would extend * > Symfony\Component\Kernel\KernelInterface* and *HttpKernelInterface* but > would be otherwise backwards compatible. This would hopefully ensure no BC > breaks and should fit nicely since the HttpKernel kernels would essentially > be implementations of the Kernel component. > > The majority of the code for *Kernel* (minus implementations for * > TerminableInterface* and *HttpKernelInterface*) and *KernelInterface*would > move to the new components: > > namespace Symfony\Component\Kernel; > > interface KernelInterface *extends* \Serializable > { > // ... code from Symfony\ComponentHttpKernel minus extending > // HttpKernel > } > abstract class Kernel implements KernelInterface { > // ... code from Symfony\Component\HttpKernel minus the > HttpKernelInterface + > // TerminableInterface implementations. > } > > The existing *Kernel* class would need to be updated to extend the new * > Kernel* and add implementations for *TerminableInterface* and * > HttpKernelInterface* from the original implementation: > > namespace Symfony\Component\HttpKernel; > > use Symfony\Component\Kernel\Kernel as BaseKernel; > > abstract class Kernel extends BaseKernel implements KernelInterface, > HttpKernelInterface, TerminableInterface > { > /** > * {@inheritdoc} > * > * @api > */ > public function handle(Request $request, $type = > HttpKernelInterface::MASTER_REQUEST, $catch = true) > { > if (false === $this->booted) { > $this->boot(); > } > > return $this->getHttpKernel()->handle($request, $type, $catch); > } > > /** > * Gets a http kernel from the container > * > * @return HttpKernel > */ > protected function getHttpKernel() > { > return $this->container->get('http_kernel'); > } > > /** > * {@inheritdoc} > * > * @api > */ > public function terminate(Request $request, Response $response) > { > if (false === $this->booted) { > return; > } > > if ($this->getHttpKernel() instanceof TerminableInterface) { > $this->getHttpKernel()->terminate($request, $response); > } > } > } > > use Symfony\Component\Kernel\KernelInterface as BaseKernelInterface; > interface KernelInterface extends BaseKernelInterface, HttpKernelInterface, > \Serializable > { > } > > There are of course a lot of other bits to worry about in here. I'm not > sure which things should be moved to the Kernel bundle vs staying in > HttpKernel. I'm sure there are some big BC things I have not considered in > moving other things around. > > The end result would be something like the following: > > use Symfony\Component\Kernel\Kernel; > use Symfony\Component\Config\Loader\LoaderInterface; > use SomeApp\Bundle\CoreBundle\SomeApp; > > class AppKernel extends Kernel > { > public function registerBundles() > { > $bundles = array( > new SomeApp\Bundle\CoreBundle\CoreBundle, > new ThirdParty\SomeAppExtensionBundle\SomeAppExtensionBundle, > ); > > if (in_array($this->getEnvironment(), array('dev', 'test'))) { > $bundles[] = new SomeApp\Bundle\DebugBundle\DebugBundle(), > } > > return $bundles; > } > > public function registerContainerConfiguration(LoaderInterface $loader) > { > > $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml'); > } > } > > $kernel = new AppKernel('prod', false); > $kernel->loadClassCache(); > $someApp = new SomeApp($kernel); > $someApp->something(); > > > In the end I could probably just use the existing HttpKernel component and > ignore the handle method. :) It would definitely save a lot of time... but > the Kernel is cool and I think that there might be other people out there > that might be more apt to use it if it was its own standalone thing and not > connected in any way to HttpFoundation, HttpKernel, or implying serving > anything over HTTP in any way. > > Is this something that is worthwhile for me to continue thinking about, > discussing, and pursuing? > > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
