Is this something I should pursue discussing and implementing? I think it could be pretty beneficial in general and would help me learn a *lot* about Symfony internals so I am excited about it. Plus, I could use this in one of my projects so I'd have added motivation to make it happen.
I'm not afraid of the work. I just don't want to waste my effort if this change is going to be unwanted and any PR related to it closed. :) On Thursday, July 12, 2012 8:06:23 AM UTC-7, 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
