Is there a possibility to construct bundle override chains in Symfony2?
For example, there is a CoreFeatureX in the product core. And there are two plugins extending that feature PluginA and PluginB.
Using standard methods from here or from here plugins can override CoreFeatureX no problem. But only one of them at a time can currently do that.
Is there a possibility to automatically construct override chains so that if both PluginA and PluginB registered in the system, they can both extend CoreFeatureX (may be, by inheriting from each other automatically) but be unaware of each other?
Similiar extension technology is used by XenForo forum system, for example. XenForo constructs an inheritance chain from plugins, that were registered as some core class extensions. It then exposes the topmost class of the extension chain as that core class itself.
Since Symfony2 doesn't let us to extend the same bundle twice at the same time, you can't to that in "clean" Symfony2.
This is clearly implemented in Symfony\Component\HttpKernel\Kernel::initializeBundles() here:
protected function initializeBundles()
{
// (...)
foreach ($this->registerBundles() as $bundle) {
//(...)
if ($parentName = $bundle->getParent()) {
if (isset($directChildren[$parentName])) {
throw new \LogicException(sprintf('Bundle "%s" is directly extended by two bundles "%s" and "%s".', $parentName, $name, $directChildren[$parentName]));
}
//(...)
$directChildren[$parentName] = $name;
} else {
$topMostBundles[$name] = $bundle;
}
}
//(...)
}
I guess this is for a reason. Anyway you could try to override Kernel class behavior of initializeBundles method (in AppKernel class). In the line where exception above if thrown, you could change parent bundle from CoreFeatureX to the last in chain.
In case of PluginB change parent bundle to PluginA because it already extends CoreFeatureX.
In case of PluginC change parent bundle to PluginB because it is on the end of current inheritance chain.
I don't know if it could work, it's just an idea. Anyway that would be an interesting experiment. ;-)
Edit.
I just notined in your comment to the question that you wrote:
But the requirement is for both PluginA and PluginB to extend
CoreFeatureX and to be unaware of each other.
Well there's something wrong here. How do you want to override one plugin by the second and on the other side make them unaware of each other? Doesn't make sense for me.
Related
For those of you that are familiar with the building of the Symfony container, do you know what is the differences (if any) between
Tagged service Collector using a Compiler pass
Tagged service Collector using the supported shortcut
Service Locator especially, one that collects services by tags
Specifically, I am wondering about whether these methods differ on making these collected services available sooner or later in the container build process. Also I am wondering about the ‘laziness’ of any of them.
It can certainly be confusing when trying to understand the differences. Keep in mind that the latter two approaches are fairly new. The documentation has not quite caught up. You might actually consider making a new project and doing some experimenting.
Approach 1 is basically an "old school" style. You have:
class MyCollector {
private $handlers = [];
public function addHandler(MyHandler $hamdler) {
$handlers[] = $handler;
# compiler pass
$myCollectorDefinition->addMethodCall('addHandler', [new Reference($handlerServiceId)]);
So basically the container will instantiate MyCollector then explicitly call addHandler for each handler service. In doing so, the handler services will be instantiated unless you do some proxy stuff. So no lazy creation.
The second approach provides a somewhat similar capability but uses an iterable object instead of a plain php array:
class MyCollection {
public function __construct(iterable $handlers)
# services.yaml
App\MyCollection:
arguments:
- !tagged_iterator my.handler
One nice thing about this approach is that the iterable actually ends up connecting to the container via closures and will only instantiate individual handlers when they are actually accessed. So lazy handler creation. Also, there are some variations on how you can specify the key.
I might point out that typically you auto-tag your individual handlers with:
# services.yaml
services:
_instanceof:
App\MyHandlerInterface:
tags: ['my.handler']
So no compiler pass needed.
The third approach is basically the same as the second except that handler services can be accessed individually by an index. This is useful when you need one out of all the possible services. And of course the service selected is only created when you ask for it.
class MyCollection {
public function __construct(ServiceLocator $locator) {
$this->locator = $locator;
}
public function doSomething($handlerKey) {
/** #var MyHandlerInterface $handler */
$handler = $serviceLocator->get($handlerKey);
# services.yaml
App\MyCollection:
arguments: [!tagged_locator { tag: 'app.handler', index_by: 'key' }]
I should point out that in all these cases, the code does not actually know the class of your handler service. Hence the var comment to keep the IDE happy.
There is another approach which I like in which you make your own ServiceLocator and then specify the type of object being located. No need for a var comment. Something like:
class MyHandlerLocator extends ServiceLocator
{
public function get($id) : MyHandlerInterface
{
return parent::get($id);
}
}
The only way I have been able to get this approach to work is a compiler pass. I won't post the code here as it is somewhat outside the scope of the question. But in exchange for a few lines of pass code you get a nice clean custom locator which can also pick up handlers from other bundles.
I'm working on a project and I'd like to ask for a clean/best way to override the steps in the
Sylius\Bundle\CoreBundle\Checkout\CheckoutProcessScenario
I'd like to preserve the custom mechanics of the whole process just add a custom step at the end and remove the finalize step.
$builder
->add('security', 'sylius_checkout_security')
->add('addressing', 'sylius_checkout_addressing')
->add('shipping', 'sylius_checkout_shipping')
->add('finalize', 'sylius_checkout_finalize')
->add('payment', 'sylius_checkout_payment')
->add('purchase', 'sylius_checkout_purchase')
;
What's the best form of doing so? If it's extending the bundle and overwriting it I'd like some help with that of at least some information to point me in the right direction - currently I'm not getting any results on my own.
I've read the docs on the bundle itself but it doesn't explain how to override the built in process.
I've also read the symfony cookbook on extending resources:
http://symfony.com/doc/2.0/cookbook/bundles/inheritance.html#overriding-resources-templates-routing-translations-validation-etc
and:
http://symfony.com/doc/current/cookbook/bundles/override.html
If anyone has some experience on the topic and would like to share thier insights I'd be very gratefull. Thanks in advance.
You could change the service class to a custom one.
You can overwrite the parameter sylius.checkout_scenario.class.
app/config/config.yml:
<parameter key="sylius.checkout_scenario.class">
Your\Class
</parameter>
I've done it a bit different but still the point was good :)
What I've done is use the service compiler to override it with my own class and override the original file. The basics are explained here:
http://symfony.com/doc/current/cookbook/bundles/override.html
in the Services & Configuration section :)
Then I just had to include the compiler pass
// src/Acme/ShopBundle/AcmeShopBundle.php
namespace Acme\ShopBundle;
use Symfony\Component\HttpKernel\Bundle\Bundle;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Acme\ShopBundle\DependencyInjection\Compiler\CustomCompilerPass;
class AcmeMailerBundle extends Bundle
{
public function build(ContainerBuilder $container)
{
parent::build($container);
$container->addCompilerPass(new CustomCompilerPass());
}
}
Inside the compiler pass I just extended the base file and overwrote the function I needed. Droppin it by in case anyone needs to pointed in the right direction.
Using https://insight.sensiolabs.com to scan / check my code, I get the following warning:
The Doctrine Entity Manager should not be passed as an argument.
Why is it such a bad practice to inject the Entity Manager in a service? What is a solution?
With respect to the comment that repositories cannot persist entities.
class MyRepository extends EntityRepository
{
public function persist($entity) { return $this->_em->persist($entity); }
public function flush () { return $this->_em->flush (); }
I like to make my repositories follow more or less a "standard" repository interface. So I do:
interface NyRepositoryInterface
[
function save($entity);
function commit();
}
class MyRepository extends EntityRepository implements MyRepositoryInterface
{
public function save ($entity) { return $this->_em->persist($entity); }
public function commit() { return $this->_em->flush (); }
This allows me to define and inject non-doctrine repositories.
You might object to having to add these helper functions to every repository. But I find that a bit of copy/paste is worth it. Traits might help here as well.
The idea is move away from the whole concept of an entity manager.
I am working on a quite a large project currently and have recently started following the approach with repositories that can mutate data. I don't really understand the motivation behind having to inject EntityManager as a dependency which is as bad as injecting ServiceManager to any class. It is just a bad design that people try to justify. Such operations like persist, remove and flush can be abstracted into sth like AbstractMutableRepository that every other repository can inherit from. So far it has been doing quite well and makes code more readable and easier to unit test!
Show me at least one example of a service that has EM injected and unit test for it looked correctly? To be able to unit test sth that has EM injected is more about testing implementation than anything else. What happens is then you end up having so many mocks set up for it, you cannot really call it a decent unit test! It is a code coverage hitter, nothing more!
Is there a way to override the controller file located at /concrete/blocks/page_list/controller.php and place it inside /packages/mypackage/blocks/page_list/? I'd like to make some changes to the original edit and view.
In /packages/mypackage/blocks/page_list/controller.php, I tried doing this but it does not seem to have any effect:
class PageListBlockController extends Concrete5_Controller_Block_PageList { ... }
You can now override/extend core classes via packages in newer versions Concrete5 (v.5.6+).
You must add to your package's main controller.php file:
public function on_start(){
$objEnv = Environment::get();
$objEnv->overrideCoreByPackage('blocks/page_list/controller.php', $this);
}
You don't have to copy over the whole core controller, just declare your new block controller like this:
class PageList extends Concrete5_Controller_Block_Page_List {
public function mymethod() {
}
}
(what class you're extending and where you put the file may vary depending on your C5 version - just compare the /concrete/ folder structure and files for reference)
The following C5 forum posts may be of help:
Overriding Core Class with Package
Can A Package Override A Core Library?
A caution, though - if you're hoping to submit to the official C5 marketplace, they generally don't accept Add-Ons with overrides.
No. You can't override a block controller from within a package. Just imagine if more than one package did this. (You can, however, have a block template within your package directory, but this makes sense because it adds rather than replaces.)
If you can, you should override by putting it in /blocks/page_list/controller.php.
However, if you still need to override it from you package, you should look into the not-very-well-supported Environment::overrideCoreByPackage() and try:
Environment::get()->overrideCoreByPackage('/blocks/page_list/controller.php', $myPackage);
See the source:
https://github.com/concrete5/concrete5/blob/master/web/concrete/core/libraries/environment.php#L123
And an example of usage:
http://www.concrete5.org/community/forums/customizing_c5/override-a-core-class-within-a-package/#460765
I'm trying to use Groovy mixin transformation on a spring-mvc controller class but Spring does not pickup the request mapping from the mixed in class.
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Mixin(Reporter)
#Controller
#RequestMapping("/a")
class AController {
#RequestMapping("b")
public String doB() {
"b"
}
}
When this code is run .../a/b url is mapped and works but .../a/report is not mapped and returns HTTP 404. In debug mode, I can access doReport method on AController by duck typing.
This type of request mapping inheritance actually works with Java classes when extends is used; so why it does not work with Groovy's mixin? I'm guessing it's either that mixin transformation does not transfer annotations on the method or that spring's component scanner works before the mixin is processed. Either way, is there a groovier way to achieve this functionality (I don't want AController to extend Reporter for other reasons, so that's not an option) ?
You can find below the responses I got from Guillaume Laforge (Groovy project manager) in Groovy users mailing list.
Hi,
I haven't looked at Spring MVC's implementation, but I suspect that
it's using reflection to find the available methods. And "mixin"
adding methods dynamically, it's not something that's visible through
reflection.
We've had problems with #Mixin over the years, and it's implementation
is far from ideal and bug-ridden despite our efforts to fix it. It's
likely we're going to deprecate it soon, and introduce something like
static mixins or traits, which would then add methods "for real" in
the class, which means such methods like doReport() would be seen by a
framework like Spring MVC.
There are a couple initiatives in that area already, like a prototype
branch from Cédric and also something in Grails which does essentially
that (ie. adding "real" methods through an AST transformation).
Although no firm decision has been made there, it's something we'd
like to investigate and provide soon.
Now back to your question, perhaps you could investigate using
#Delegate? You'd add an #Delegate Reporter reporter property in your
controller class. I don't remember if #Delegate carries the
annotation, I haven't double checked, but if it does, that might be a
good solution for you in the short term.
Guillaume
Using the #Delegate transformation did not work on its own, so I needed another suggestion.
One more try... I recalled us speaking about carrying annotations for
delegated methods... and we actually did implement that already. It's
not on by default, so you have to activate it with a parameter for the
#Delegate annotation:
http://groovy.codehaus.org/gapi/groovy/lang/Delegate.html#methodAnnotations
Could you please try with #Delegate(methodAnnotations = true) ?
And the actual solution is:
class Reporter {
#RequestMapping("report")
public String doReport() {
"report"
}
}
#Controller
#RequestMapping("/a")
class AController {
#Delegate(methodAnnotations = true) private Reporter = new Reporter
#RequestMapping("b")
public String doB() {
"b"
}
}
When you map requests with annotations, what happens is that once the container is started, it scans the classpath, looks for annotated classes and methods, and builds the map internally, instead of you manually writing the deployment descriptor.
The scanner reads methods and annotations from the compiled .class files. Maybe Groovy mixins are implemented in such a way that they are resolved at runtime, so the scanner software can't find them in the compiled bytecode.
To solve this problem, you have to find a way to statically mixin code at compile time, so that the annotated method is actually written to the class file.