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 again. I couldn’t find anything in the docs … In spryker it is possible to add different logi
Hello again. I couldn’t find anything in the docs … In spryker it is possible to add different logic for different stores by adding a suffix to the modulename. The module resolver will pull that piece of logic first. But are there also possibilites to “group” logic somehow? For example if you have an EU region with AT, DE, CH store and a US region with AZ, CO, CT … for all the US store you want to have a specific piece of logic that will calulcate your shipping costs in the same way for all US based stores … is that possible without creating a specific module with a corresponding suffix for each store? ShippingAZ, ShippingCO … just for interest because its some kind of work we want to avoid whenever we add a new store that should follow the same “logic group” … or is there another way here? I would really like to stick to one common codebase since there is no much difference between all the shops, just in few points … Best regards and have a nice day 😉
Comments
-
You could have an EU Store with different locales and possibly different databases for your case.
As far as I know there is no way to group stores.If you want to keep the separation between DE, AT, etc. and have a logic shared between AT and DE, but not for US and CO, which will share the same logic, you could have a look on the strategy pattern, but it’s not supported out of the box.
But as you described that there is not so much difference, you better go with one store for EU and one for US.
Stores does not mean you are bound to one locale per store 😉0 -
Stores does not mean you are bound to one locale per store
Please correct me if i am wrong but the locales stuff is just for controlling languages, translations, urls etc … but the content of the shop is still the same … so you can’t control things like “Product A should be visible in store DE but not in AT” or am i wrong? 🤔 So i think we have to use the store logic because yes, they should also have different content for each store …
0 -
I will have a look at the strategy pattern anyway. Thanks!
0 -
Dunno if I understand you correctly, but we do it with ModuleNameSTORENAME
0 -
depending of course on the amount of customizations you need to do for each region, I would consider solving that in the code, having just one “Shipping” module and implementing f.e. like “Strategy” pattern, like Alberto mentioned
0 -
@UK7KBE2JW i think you did not got the problem correctly … the problem is: what if you would like to have a different logic ONLY for ALL us stores but not for any EU store? This would mean you would have to create a specific ModuleNameSTORE directory for each us store … like ModuleNameTX, ModuleNameCA, ModuleNameUT … when you have 50 US states and for each state one store … then you would create 50 directories per touched module … that cannot be the solution
0 -
Maybe someone had a similar case … i could also imagine using different code bases but than the difficulty would be to put all the required logic together in one module that can be attached to each new codebase … at the moment, the code is spread over different modules in the project
0 -
Hello again, does anybody has already implemented this “strategy pattern” with spryker? So is it meant to be only applied on the corresponding code were its needed (business logic/ facade etc.) or should it be applied one step higher on the level were the classes (factories, denpendency provider etc) getting resolved? So for me it would be cleaner to have it at a higher level to choose the correct module folder but i don’t see any chance to do so without changing the core class resolver implementation, which might lead to incalculable behavior. So any example implementations here? Some advices?
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 73 Spryker News
- 910 Developer Corner
- 770 Spryker Development
- 87 Spryker Dev Environment
- 361 Spryker Releases
- 3 Oryx frontend framework
- 34 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 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
- 32 Product & Business Questions
- 69 Spryker Safari Questions
- 50 Random