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..
(Untitled)
Comments
-
I would love this come to fruition!
0 -
unfortunately, that would require an entirely different implementation of the state machine ๐
0 -
but for sure an interesting concept
0 -
Letโs have a discussion in the comments! I also added my 5 cents. I do like state machine, and I donโt always like step engine implementation, but Iโm afraid state machine wonโt help here, although sounds temting
0 -
can just be steps that declare dependencies
0 -
regarding the implementation - it could be implemented as a separate spryker-shop module, but yes - current state machine is a โzedโ module
0 -
no need to integrate into the existing state machine(s)
0 -
do you have a use case?
0 -
any checkoutout procedure that branches based on user choices / quote (there are lots in the wild)
0 -
state machine in itโs current implementation will bring lots of redundancies into the process, with itโs timeouts, cron jobs, state history and so on.. Probably, you would need another state machine there..
0 -
but not off hand ๐ only the relatively trivial example in the idea and vague recollections of writing a VoIP checkout 10 years ago ๐
0 -
the question is: how complex can this really get in real life scenarios
0 -
the more i think about it, the less.i think it is a good idea ๐
0 -
a step "engine" should be modelled as a graph - you have steps that depend on other steps
0 -
validation complexity simply explodes when you have many ways that can lead to the current state and you allow to randomly visit prior states
0 -
sounds like a bug engine ๐
0 -
"randomly visit prior states" is not required here. Defined paths but just more complex paths.
0 -
why not start different step engines then?
0 -
because you could branch at arbitrary points
0 -
exactly
0 -
so you can't just choose a correct linear progression to start with
0 -
anyway
0 -
this would make for a fun whiteboard session and maybe even a hacknight topic
0 -
I think we would need to discuss an exact checkout flow example cause you can achieve quite a lot by manipulating Step postConditions and just skip steps you do not require
0 -
a little bit of cheating in the step factory can also allow dynamic configuration
0 -
but would be a bit hacky
0 -
the original point is that you can't skip steps. You have to run through them, so I think at least the possiblity of disabling steps would be a start, anyway - but a graph based system would seem to fit closer to real life (depending on use case) but the linear flow fits into the graph flow anyway.
0 -
how hard can that be? (famous last words ๐)
0 -
the only thing I am missing is checking for
postConditionatSpryker\Yves\StepEngine\Process\StepCollection.php::getNextStep()so you do not need to go to next step if the postCondition is already met and skip to next one0 -
it will redirect to that step before checking it though
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 80 Spryker News
- 952 Developer Corner
- 809 Spryker Development
- 91 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 36 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 26 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