Closed Richtermeister closed 10 years ago
Hi,
Thanks for all.
I'm aware of this issue, and it will definitely be the feature to work on for 1.1 release.
The property path solution is maybe the way to make it, i'll let you know as soon i have some time.
@Richtermeister I've not decided yet if I'm pro or not about this, the question is a bit controversial, states of states of an entity...
In most of case, the need for many state graphs can be expressed by a more complex, but single state graph.
Anyway, I think multi-state graphs is a needed feature, so it's planned ;)
:+1:
Actually, I thought about this some more and we might not need a big change here. I can just wrap the managed object into another class which implements StatefulInterface
and manages one of the states. In the simplest case this can be a new class StatefulProperty
which wraps the object and uses the PropertyAccess
internally. In a more complex state the user can implement their own wrappers. I think this would totally cover our use-cases and would not even require any changes to the current library..
And to clarify, I'm perfectly happy with several individually managed states. They don't have to be connected into a multi-state graph (just yet.)
@Richtermeister Is it possible to add a payment and shipping object and associate it with the order? That’s how I do it.
If it doesn’t increase complexity too much I’m also +1 for adding property paths and having multiple states.
I started implementation of property-access and multiple state-graphs.
Here is an example : https://github.com/yohang/Finite/blob/feature-multiple-graph/examples/multiple-graphs.php
Closing as #28 is merged.
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..