Added the support for class inheritance and skipping handlers

[shiroyuki]

(Originally submitted as #175)

This PR is to add the support to allow the handler to tell the graph navigator to skip itself and proceed with the normal procedure. For instance,

use PhpOption\None;

class MyHandler implements SubscribingHandlerInterface
{
    public function serializeProxy(JsonSerializationVisitor $visitor, $entity, array $type, Context $context)
    {
        if ($visitor->getRoot() === null) {
            throw new SkipStepException('Skip This');
        }

        return array(/* ... */);
    }
}

Also, this PR supports the class inheritance such that we can specify a parent class in getSubscribingMethods. For instance,

class MyHandler implements SubscribingHandlerInterface
{
    public static function getSubscribingMethods()
    {
        return array(
            array(
                'direction' => GraphNavigator::DIRECTION_SERIALIZATION,
                'format' => 'json',
                'type' => 'EntityParentClassOrInterface',
                'method' => 'serializeProxy',
            ),
        );
    }

    public function serializeProxy(JsonSerializationVisitor $visitor, $entity, array $type, Context $context)
    {
        /* ... */
    }
}

[shiroyuki]

Ping @kinncj and @guilhermeblanco

[kinncj]

At least the class inheritance support is primordial.
👍

[schmittjoh]

Thanks for cleaning up the pull request. Unfortunately, I think you can already achieve both features with what we already have. Let me explain a bit:

If you would like to catch a base class with a handler, you can already annotate the respective properties with the @Type annotation hinting the base class and register a handler for the base class. The current handler system was meant as a simple key-value lookup table for fast access. The strings do not necessarily have to correspond to class names.

Similarly, the SkipStepException can be solved by calling accept with a different type name. You could for example, use any arbitrary string as type which your handler responds to and then call accept again with a different type from within your handler. This should also be faster than throwing/catching an exception.

[bdecarne]

Johannes,

This post is kind of old, but about class inheritance : the @type annotation could do the job, but it can't be used on the class level. If i try to serialize the object, i cant use the handler define for the parent class...

I have a master class FormFlow, and i try to serialize a object instance of CreateItemFormFlow, subclass of FormFlow. How can i achieve that ?

[goetas]

Sorry for the terribly long feedback loop

Closing the PR, since too many things changed on master in the last years. If you are still interested in working on this feel free to re-open a new PR based on the current master including proper tests

[goetas]

re opening to keep track of it as feature request

[goetas]

@Majkl578 what do you think about SkipStepException ?
Whar said by @schmittjoh

Similarly, the SkipStepException can be solved by calling accept with a different type name. You could for example, use any arbitrary string as type which your handler responds to and then call accept again with a different type from within your handler. This should also be faster than throwing/catching an exception.

is not true, as the object is already in visiting state, so another call to accept will just return null

[goetas]

The part of "skipping handlers" has been implemented in #1238 (it was already possible to implement something as that in the past, but it requited a two-steps approach, while now can be done in a single one).

Regarding the inheritance, I think that @schmittjoh answer it explains how to use the @Type annotation to achieve it.

If you would like to catch a base class with a handler, you can already annotate the respective properties with the @type annotation hinting the base class and register a handler for the base class. The current handler system was meant as a simple key-value lookup table for fast access. The strings do not necessarily have to correspond to class names.