What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello everybody, is there a recommended way pulling plugins as a dependency to another module when t

Options
UPWG9AYH2
UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet

Hello everybody,
is there a recommended way pulling plugins as a dependency to another module when the plugin itself has dependencies? I want to use that code of this plugin in my own module. Usually, the plugin has no dependencies at all (no constructor params), but now i hit encounter a spryker plugin that has DI params which is a new situation to me … any ideas how to deal with it? 🤔 the class is the spryker yves CustomerAuthenticationFailureHandler.
Best

Comments

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    I’d say Plugins should not be considered as Services you should deal with DI

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Plugins from a conceptual point of view are a layer for more dynamic “DI” wiring in a way?

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    That does not solve your issue here though, I guess 😁

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Hi Andreas. That means, the plugins dependecies itself should also be defined as a dependency in the DI of the module the plugin is pulled to?

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Plugins, PluginStack, etc though are often residing in PyZ for a reason. To be explicitly managed, I’d say

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Wait, it’s not directly a plugin, but a handler class, residing in a Plugin namespace 🤔

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    That was also my feeling … not really a plugin

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    At least not in the sense of sprykers “use it in other modules” approach^^

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    yep. meaning nope 🙂

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    But you need to get access to that service instance to inject it somewhere for sure?

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    I wrote a new authenticator but moved to another module for that … the authenticator should handle success and errors as before so the idea was to use the handler-plugins in my module … but thats not possible with this dependency … i think ill move from the new module back in the origin modules space so i can instantiate the handlers via the factories … might not be the best solution but less stressfull i guess^^

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    oooor you implement your own \Symfony\Component\Security\Http\Authentication\AuthenticationFailureHandlerInterface 🤔

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Yeah … just want to avoid a copycat/code duplication^^

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Or go with the approach you initially thought about. Pulling in the dependencies for the handler and instantiate it within your module. A bit of tech smell, but that’s probably for all the options you have

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Well, what would be the worst impact of that?

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    The handler isn’t doing as much

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    I think the cleanest option would be to stick to the origin module with my new authenticator as long as there is no need to separate it as a module that can be used in other projects … for the moment there isnt such a requirement … but perspectively it would be nice to have a clean dependency on that and just add a composer dep for that

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Or go with the approach you initially thought about. Pulling in the dependencies for the handler and instantiate it within your module. A bit of tech smell, but that’s probably for all the options you have

    The thing is, the DI itself would be a dependency .. in this case the messenger … so if i would it also add to the dependency provider as well, i think there is a smell since there is the chance that the dep is not loaded yet

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    Not sure if I can fully follow. Making the feature you worked on a standalone module, having a dependency to that auth handler sounds like a risk though, yes.

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Yeah but a clearly defined one^^i mean its always a tradeoff … if i don’t want to re-implement a feature that already behaves as i want, i get some kind of dependency to it … i think thats the price^^

  • UKJND3A3H
    UKJND3A3H Posts: 123 🧑🏻‍🚀 - Cadet
    Options

    yep 🙂