EZP-20097 Specify a api to field types for dealing with relation handling

[pspanja]

This PR implements issue EZP-20097.

External storage is not used for storing relations anymore, instead a new method, getRelations(), is added to the FieldType interface and used from service to process and store Field relations (LINK, EMBED and FIELD types). For this an internal service RelationProcessor is implemented.

Also, ContentHandler::removeRelation() gets a second parameter $type, since Legacy Stack stores Content level relations (LINK, EMBED and COMMON types) into a same row using bitmask. Legacy Stack is capable of processing non-merged entries, so it is not required to update it not to use relation type bitmask. In time second parameter $type should be deprecated.

Alternatively it should also be possible to patch LS not to store relations with bitmask and thus avoid second parameter to removeRelation() (not probable anyone depends on ezcontentobject_link.id since they change with every update).

Linked with this PR:
ezsystems/ezpublish-legacy#529
ezsystems/ezoracle#13

[patrickallaert]

Since the same think is done for LINK and EMBED, this could be handled with a unique condition:

if ( $relation->type & ( Relation::LINK | Relation::EMBED ) )

[pspanja]

Indeed, fixed in 6ec5602

[andrerom]

Beside the comment by Patrick, big +1

[patrickallaert]

Nitpick: I would probably have written this with a unique loop and a switch statement to decrease cyclomatic complexity and increase clarity.

    // Remove relations not present in input set
    foreach ( $mappedRelations as $relationType => $relationData )
    {
        foreach ( $relationData as $relationEntry )
        {
            switch ( $relationType )
            {
                case Relation::FIELD:
                    foreach ( $relationEntry as $relation )
                    {
                        $this->persistenceHandler->contentHandler()->removeRelation(
                            $relation->id,
                            $relationType
                        );
                    }
                    break;
                case Relation::LINK:
                case Relation::EMBED:
                    $this->persistenceHandler->contentHandler()->removeRelation(
                        $relationEntry->id,
                        $relationType
                    );  
            }
        }
    }

[pspanja]

Added in 83a5e07 :)

[patrickallaert]

Besides my nitpicking, huge +1 :)

[pspanja]

Thanks for the review guys!

[andrerom]

So everything ready? :)

[pspanja]

Nope :)

There are few fails with stubs, I need to update that first.

[andrerom]

Is it ready now? :)

( You should use sub tasks list to signal readiness of PR ;) see: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments )

[pspanja]

Yes it's ready, but linked PRs on ezpublish-legacy and ezoracle should go together with it.

[andrerom]

Ok, good you mentioned that, ezsystems/ezpublish-legacy#529 seems to need a update to be mergable.

[pspanja]

Ok, I just rebased it.

[andrerom]

Thanks, it's now all in :)

[tobyS]

The data structure does not look very clean. Nested structure can better be realized using structs, which has the benefit of autocompletion and better code checks in IDEs and tools. Also, having multiple possible values for a single key should be considered bad practice. Decide for a single, flexible format instead and stick to it.