First, really nice project, i love it !

Is it possible to split Finite as standalone component without the symfony stack inside ? and add the symfony bundle on top ?

Currently on non symfony project (like silex or cilex) it's a bit frustrating to see a bundle folder appear :D

Is it plan ?

Hi,

This PR adds 2 useful things:

1. The ability to pass arguments to callbacks. Currently, we are limited to the arguments $object and $transitionEvent. With this PR you can define arguments to pass to your callback directly from the graph configuration (via the args parameter).
2. A simple callback that you can use (in combination with the callback arguments :) to cascade some transitions. I updated the callback.php example with an automatic transition from accepted to archived. This can be useful in many cases. The callback supports as well the cascade when dealing with the same object but different graph, and even with another object reachable from the main object via a PropertyAccessor (for example, when your shipment goes from ready to shipped, you may want to automatically update your order (reachable with shipment.order).

Thanks,

We had an issue with Finite installing along symfony/options-resolver 2.6+ which caused E_DEPRECATED errors due to new syntax of setAllowedTypes method. This little fix removes the error, it is however optional, because you have 2.4.4 in your composer.lock file (which was somehow ignored in our system). You could add this to prevent problems with update to 2.6+/3.0 of options-resolver or simply ignore this, as manual specification of "symfony/options-resolver": "2.4.4" in our composer.json seemed to do the trick too.

Cheers.

Related to issue #84.

It would be useful to be able to pass params to transition events. See the doc for more details

| Q | A | | --- | --- | | Test Pass? | y | | License | MIT |

Hi Yohan, very nice project!

We have been looking at it from over at https://github.com/Sylius/Sylius/issues/1037, but one problem we have that the use of the StatefulInterface limits each object to only one state. In Sylius we have an Order class which has several states, such as ShippingState, and PaymentState.

Would it not be possible to get rid of the interface and instead rely on the PropertyAccess component to access whichever property represents the state?

Another (more explicit) possibility would be to rely on a new StateExtractorInterface which would be used to extract a single state from an object..

If you agree that this is a limitation that we should/could address, I would be happy to help with the implementation..

TODO

• [x] Add a callback handler
• [x] Add Symfony EventDispatcher as an hard dependency
• [x] Deprecate ListenableStateMachine and make the base State machine listenable
• [x] Link ArrayLoader and the CallbackHandler to define callbacks from configuration
• [ ] Update the Symfony Bundle
• [x] Add docs and examples

(Inspired by @tortuetorche work here : https://gist.github.com/tortuetorche/6365575)

Do you think you could tag a stable release? Would be great since more recent projects using Composer do only use stable releases by default. Also gives somewhat more confidence to use the project by other people.

It does work on my windows development machine (php version 5.4.27) but it doesn't work on linux test or production server with php 5.4.33 The error I'm getting is: request.CRITICAL: Uncaught PHP Exception Symfony\Component\OptionsResolver\Exception\InvalidOptionsException: "The option "disabled" does not exist. Known options are: "exclude_from", "exclude_to", "from", "on", "to"" at /var/www/vhosts/xxxxxxx.local/httpdocs/vendor/symfony/symfony/src/Symfony/Component/OptionsResolver/OptionsResolver.php line 255 {"exception":"[object](Symfony\Component\OptionsResolver\Exception\InvalidOptionsException: The option "disabled" does not exist. Known options are: "exclude_from", "exclude_to", "from", "on", "to" at /var/www/vhosts/xxxxxxx.local/httpdocs/vendor/symfony/symfony/src/Symfony/Component/OptionsResolver/OptionsResolver.php:255)"

state-machine.yml is

    callbacks:
      after:
        callback1:
          do:
            [@xxxxxxx_finite.transition_events, transitionEverytimeAfter]

Here is a draft of the refactoring of the CallbackHandler (#48).

It introduces no BC, but it deprecates the previous usage of CallbackHandler::add* methods.

Callbacks are now wrapped in a Callback, with a CallbackSpecification responsible of the execution, or not, of the callback on transition events.

Callback defines an __invoke method, and instances are directly registered as event listeners.

The Callback instantiation logic has been moved to a CallbackBuilder and to the ArrayLoader.

I kept the options resolver, as it's pretty good at cleaning configuration arrays.

Only today I came across this library, after a few hours of study and running a few examples, I came across the following:

• Warning if I do not pass a guard option when defining a transition: PHP Notice: Undefined index: guard in vendor/yohang/finite/src/Finite/Loader/ArrayLoader.php on line 109. I did not see any reference of this property in the examples.
• I was expecting that by calling the method reject() on the TransitionEvent, this would abort the transition, but not the case, it seems it has no impact. The method apply() on StateMachine, after dispatching the pre events, call process() on the Transition, but that method has an empty body, it does not return any value, but still, we use that as the return value of the apply(). Is this by design, are we suppose to create/extend the Transition class and implement our logic in the process method()?

We've been using your library (via kphoen/doctrine-state-machine-bundle) and as a push for getting ready for Symfony 2.8 / 3.0, we've been trying to eliminate all deprecated warnings in our code and the third party libraries that we use.

This PR represents the changes that were required for preventing this library from causing the warnings. It represents a culmination of the code in #90, #85 and #79 (and maybe some extra too)

In addition, I have made the following composer related changes:

• I have also removed the composer.lock file, as it's generally superfluous in a library designed for consumption by others.
• I have updated the composer.json requirements for Symfony versions to be ~2.6

The required changes in symfony versions means that this PR has BC compatibility issues for people using it in projects with older versions of Symfony, so in the strictest semver terms, it would require a new major release.

If you have any issues, please let me know. Would love to see the deprecation issues addressed.

Thanks. :+1:

Hey there @yohang ,

this repo and the library does not get the love it deserves. There are multiple open issues and a LOT of PRs ready to be merged or at least tested. People invest in this repo an obviously the interest in this repo is big with over a million installs on Packagist and over 150 forks here on GitHub.

Since you seem to be unable/unwilling to maintain this library for the community on your own, would you be willing to enable one of your contributers (if they are willing) to moderate and administer this library for or at least with you?

@winzou @navitronic @RonRademaker @Padam87 @liuggio @tortuetorche @tompedals @pborreli @nidup @defrag @arikal @realshadow @K-Phoen @acorncom @dannykopping @ksn135 @reiz

The other path would be to mark this project as abandoned, so people would stop installing it and then realize that there are (known) bugs, that are not fixed or missing functionality that is not merged, even when the work is done.

This should neither be attacking nor judgemental. I know, it is hard to maintain open source and interact with a community if you already have a demanding life out there in the real world and a company whatsoever. But I also think, that it is unfair to the community to let them use software without a clear message that this library is not maintained actively.

I have tested the examples. Examples multiple-graphs-with-factory.php and multiple-graphs.php do not work. Here is what we get.

php multiple-graphs-with-factory.php
PHP Fatal error:  Class 'Pimple' not found in vendor/yohang/finite/examples/multiple-graphs-with-factory.php on line 77

php multiple-graphs.php
PHP Fatal error:  Uncaught exception 'Symfony\Component\PropertyAccess\Exception\NoSuchPropertyException' with message 'Neither the property "finiteState" nor one of the methods "getFiniteState()", "finiteStat\
e()", "isFiniteState()", "hasFiniteState()", "__get()" exist and have public access in class "Order".' in vendor/symfony/property-access/PropertyAccessor.php:516
Stack trace:

I'm using Symfony 4.4. The documentation at https://finite.readthedocs.io/en/master/usage/symfony.html#using-callbacks say:

Events dispatched with the EventDispatcher and works as the Symfony kernel events.

This would seem to imply that one can simply follow the standard Symfony ways of registering an event listener. i.e. using services.yaml or Creating an Event Subscriber.

However, neither of those work, because Finite creates its own event dispatcher! When a new StateMachine is created, it creates a new StateMachineDispatcher() which creates...a new Symfony\Component\EventDispatcher\EventDispatcher.

So any Symfony event registered in the normal way will not listen to the event.

Solution

We have to connect our event listener to the StateMachine's dispatcher.

$sm = new StateMachine();
$dispatcher = $sm->getDispatcher();
$dispatcher->addListener(FiniteEvents::POST_TRANSITION, [new MyPostTransitionListener(), 'onFinitePostTransition']);

class MyPostTransitionListener
{
    public function onFinitePostTransition(\Finite\Event\TransitionEvent $event)
    {
        // handle event here
    }
}

If symfony/contracts is also used in the project, there versions 1.2.* have an issue:

TypeError : Argument 2 passed to Symfony\Component\EventDispatcher\EventDispatcher::dispatch() must be an instance of Symfony\Component\EventDispatcher\Event or null, instance of Finite\Event\StateMachineEvent given

This seems to occur when someone has both the Symfony\Contracts\EventDispatcher\Event and Symfony\Component\EventDispatcher\Event installed. This check in StateMachineEvent checks whether Symfony\Contracts\EventDispatcher\Event exists, and aliases it to Symfony\Component\EventDispatcher\Event if not.

All automated tests pass, but I haven't tested all functionality in-depth. Probably want to merge this into a different branch to test further.

This PR allows use of this repo with Laravel 7. Without these changes, composer hangs indefinitely trying to resolve dependencies that include Symfony 5.x.