-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decorator extension used with Search extension #215
Comments
It should be fixed by #197, can you check it out? |
Ouch, sorry did not see that. Yeah it fixes the problem. Thank you! Now it is correctly in the DI set with tag. Unfortunately, it created a new problem xD Since nettrine/dbal's extension is now before the Decorator. It's beforeCompile does not know about the tag, because it is not yet assigned, but that discussion I will move to nettrine/dbal issue. https://github.com/nettrine/dbal/blob/master/src/DI/DbalExtension.php#L155 |
I think this is a more complex problem. I will not release the version with #197 yet. |
@dg Another way could be adding Search and Decorator (in this order) to the
That way services from Search would be decorated correctly and any other extensions relating on tags from Decorator would be satisfied. On the other hand, this would break extensions which only add services and rely on decorator to decorate them - which is a bad idea anyway. Edit: It might also break extensions adding services manually because Search would register them before... |
Currently I assume in:
I think we all have some expectances in which order thinks should happen. Unfortunately it will be never same for all of us. Search and decorator extension do to much, both of them simply cannot work in every single case -> there would be always some issues. If we register search extension in If search extension is in Search or decorator extensions not prioritized? We cannot expect anything -> random errors, biggest no way. Even prioritization of extensions based on hierarchy of composer dependencies would not work in this specific case. My proposal is complete removal of the expectations. Whole Conceptually it adds listeners which:
Phase 1 - Extensions setup their event listeners Phases as I wrote comes with expectance events are triggered after all services are registered. But if addition of services would be allowed in events phase (phase 4) then we should ensure only fully initialized, valid services are added to container builder (which would call event dispatcher) so modification events are not triggered instead of creation events and changes from events are not mixed into initialization. This would need instead Only thing I worry about is that with great power there must also come great responsibility. Events over-usage may cause cyclical dependencies, so we would need a loop detection. |
@mabar I was thinking in same ways as you. About the expectations and that every possible solution breaks in some situation, but I believe your proposed approach is overly complex and difficult to maintain. Simple reordering from my previous comment breaks manual registration of services. I would suggest to reorder - search and decorator to |
Simply adding decorator to |
any news about this? edit: more I think I believe solution with allowing setup directly in search extension would actually be only possible solution, otherwise you're allways in issues with priority of what loads when. If stated in docs that search extension supports all stuff like decorator and that decorator cannot be in use with services registered with search extension it sounds like only possible solution ATM that won't break anything and allow full functionality.... |
should be fixed in master |
@dg Still not working for this use case. <?php declare(strict_types = 1);
namespace App\Components;
abstract class Component
{
protected Translator $translator;
public function setTranslator(Translator $translator): void
{
$this->translator = $translator;
}
}
final class Foo extends Component
{
}
interface FooFactory
{
public function create(): Foo;
} search:
default:
in: %appDir%
classes:
- App\Components\*Factory
decorator:
App\Components\Component:
setup:
- setTranslator |
@FVesely fixed |
Version: 3.0.0
Bug Description
When I use Decorator together with Search extension it does not decorate services. It is in the DI, but does not have tag.
If I insert service definition directly without the use of Search extension, then it does work as expected.
Steps To Reproduce
Expected Behavior
Acme\Subscriber\LifecycleSubscriber
class should be in DI decorated with tagnettrine.subscriber
.The text was updated successfully, but these errors were encountered: