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 All, I've extended the MailToMailerBridge class and added a new method also i have created the
Hello All, I've extended the MailToMailerBridge class and added a new method also i have created the interface for the same but getting this below error during travis check on this following command run spryker/architecture-sniffer below is the error screenshot and code. Anyone have any idea on this?
Comments
-
Projects should not use bridges. Those are core-only (vendor) specific classes.
0 -
As mentioned in documentation:
@(Error)()(Bridges are for core-level only. If you use them at the project-level, you are doing it wrong!)
0 -
So I can extend it in project level right?
0 -
No, you can directly use the interfaces and classes
The bridge concept is for decoupling of modules, which is not needed for wiring on project level. See docs.0 -
Exactly, as Mark said, you can just use the locator to grab the facade directly and use it’s interface
0 -
By the way, if we just use the interfaces directly on project-level, how are we supposed to handle cases where we depend on type-hints?
A short Example: SalesToStoreInterface is being used as type-hint of method getStoreFacade() in SalesBusinessFactory. When we now pass our own StoreFacadeInterfacade (and not SalesToStoreInterface) in the SalesDependencyProvider, this typehint will be broken. If we override getStoreFacade(): StoreFacadeInterface in our projects SalesBusinessFactory, this will be a php error (because they are not compatible). What's the suggested approach here?
0 -
Param/Return types are indeed somewhat troublesome in such cases.
If there are not solvable, you can use an adapter like approach (just dont call it Bridge then and the sniffer should also be fine).0 -
U have to define the construct again in your class on pyz level
/** * @var \Swift_Message */ protected $message; /** * @var \Swift_Mailer */ protected $mailer; /** * @param \Swift_Message $message * @param \Swift_Mailer $mailer */ public function __construct($message, $mailer) { parent::__construct($message, $mailer); }
and then the architecture sniff would be ok..
0 -
and if u have still the problem, of course smth so can also solve your problem to ignore this rules
/** * @SuppressWarnings(PHPMD.BridgeMethodsRule) * @SuppressWarnings(PHPMD.BridgeMethodsInterfaceRule) */
0 -
Also, if you have your facade, you should usually implement all the core bridge interfaces there so everything internally in core would work seamlessly
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 77 Spryker News
- 938 Developer Corner
- 795 Spryker Development
- 90 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 27 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 33 Product & Business Questions
- 69 Spryker Safari Questions
- 50 Random