In Workflow Component there is the Workflow service that makes possible to do something lie this:
$post = new BlogPost();
$workflow = $registry->get($post);
$workflow->can($post, 'publish'); // False
$workflow->can($post, 'to_review'); // True
$workflow->apply($post, 'to_review');
$workflow->can($post, 'publish'); // True
$workflow->getEnabledTransitions($post); // ['publish', 'reject']
Here in Subscription we should be able to do something like this:
$subscription = $entity->getSubscription();
$set = $registry->get('feature_set');
$set->has($subscription, 'publish'); // False
$set->apply($subscription, 'to_review');
$set->getEnabledFeatures(subscription);
// ecc...
The Subscription has to be stored as a json string directly in the entity that uses the subscription and not in a separate table.
This makes possible to completely remove the table storing the subscriptions and avoid unuseful duplicates of rows.
In fact, this structure often causes that a subscription row is required for each corresponding entity (like what happens in our apps that handle redirects).
v0.12.0
v0.13.0
Not planned yet.
In Workflow Component there is the
Workflowservice that makes possible to do something lie this:Here in Subscription we should be able to do something like this:
The Subscription has to be stored as a
jsonstring directly in the entity that uses the subscription and not in a separate table.This makes possible to completely remove the table storing the subscriptions and avoid unuseful duplicates of rows.
In fact, this structure often causes that a subscription row is required for each corresponding entity (like what happens in our apps that handle redirects).
v0.12.0
FeaturesManagerand create aSubscriptionManager(to evaluate)...
0.13.0v0.13.0
Not planned yet.