Provide way to register serialization classes

I think we should use plugins to register all available NEDD components. I still need to wrap my head around the plugin system overall, so I cannot tell if it supports the alter workflow we want. So just go with drupal_alter() for now.

I think jslond.module should be a submodule of serialization.module, i.e. serialization_jsonld.module.

I'm wondering how the serialization API of symfony could play with the typed data API. I guess, we could use the typed data API as our normalized data representation. That way encoders would have all metadata available and could leverage them as necessary, e.g. to apply the RDF mapping. Makes sense?

The general structure in #9 looks good to me. I'm not sure if the intent is to commit it as is and then add stuff to it, or wait until we have more to add, but this looks conceptually sound.

Code looks good. We don't need this as a module though. We can add the classes to core/lib/Drupal/Core/Serialization and the 'serializer' service registration in CoreBundle.

I'd be fine with either this being committed on its own, or rolled into #1811510: Enable JSON-LD entity serialization.

Some nits:

+++ b/core/modules/serialization/lib/Drupal/serialization/RegisterSerializationClassesPass.php
@@ -0,0 +1,68 @@
+/**
+ * Adds servies tagged 'nested_matcher' services to the tagged_matcher service.
+ */

Copy/paste leftover.

+++ b/core/modules/serialization/tests/modules/serilization_test/lib/Drupal/serialization_test/SerializationTestEncoder.php
@@ -0,0 +1,43 @@
+class SerializationTestEncoder implements EncoderInterface {
+  /**

Add a linebreak between these lines.

+++ b/core/modules/serialization/tests/modules/serilization_test/lib/Drupal/serialization_test/SerializationTestNormalizer.php
@@ -0,0 +1,50 @@
+class SerializationTestNormalizer implements NormalizerInterface {
+  /**

Add a linebreak between these lines.

+++ b/core/modules/serialization/tests/modules/serilization_test/lib/Drupal/serialization_test/SerializationTestNormalizer.php
@@ -0,0 +1,50 @@
+    // If this is an Entity object and the request is for JSON-LD.
+    return static::$format === $format;

Copy/paste leftover of code comment.

Additionally:

+++ b/core/modules/serialization/lib/Drupal/serialization/RegisterSerializationClassesPass.php
@@ -0,0 +1,68 @@
+   * Adds services tagged with normalizer or encoder to the Serializer.

normalizer and encoder should have quotes around them?

+++ b/core/modules/serialization/lib/Drupal/serialization/RegisterSerializationClassesPass.php
@@ -0,0 +1,68 @@
+   * The highest priority number is the highest priority (reverse sorting).

Really? This is against the Drupal way of weight priorities where high numbers sink down. Is this necessary because the Symfony serialization stuff expects it this way?

+++ b/core/modules/serialization/lib/Drupal/serialization/RegisterSerializationClassesPass.php
@@ -0,0 +1,68 @@
+   * @param array $array
+   *   A nested array of Normalizers/Encoders.

$array is a really bad variable name. How about $components or similar?

+++ b/core/modules/serialization/lib/Drupal/serialization/RegisterSerializationClassesPass.php
@@ -0,0 +1,68 @@
+    foreach ($array as $a) {
+      $sorted = array_merge($sorted, $a);
+    }

why is that necessary? Why can't you just return $array after krsort()? Please add a comment.

+++ b/core/modules/serialization/lib/Drupal/serialization/SerializationBundle.php
@@ -0,0 +1,28 @@
+    $container->register('serializer', 'Symfony\Component\Serializer\Serializer')
+      ->addArgument(array())
+      ->addArgument(array());

why do you need the empty arrays? The default values of Serializer's constructor are arrays anyway?

+++ b/core/modules/serialization/lib/Drupal/serialization/Tests/SerializationTest.php
@@ -0,0 +1,46 @@
+  public function testSerilizerComponentRegistration() {

I think you should also test the encoder by actually invoking it and comparing the final serialized output.

+++ b/core/modules/serialization/tests/modules/serilization_test/lib/Drupal/serialization_test/SerializationTestEncoder.php
@@ -0,0 +1,43 @@
+  /**
+   * Implementation required. This function not used for testing.
+   *
+   * @param mixed $data
+   *   Data to encode
+   * @param string $format
+   *   Format name
+   */
+  public function encode($data, $format) {

As said, this function should be used for testing. And all parameter descriptions should en with proper punctuation.

Thinking more about the term "priority": higher numbers mean higher priority, which is probably fine. So if we reverse that we should also rename "priority" to "weight". I think that is follow-up stuff, so just ignore that for now.

Ah, I see the replaceArgument() calls now, so better also add a comment to the empty addArgument() calls if they are required.

Regarding the test: right, so calling one method on the encoder suffices to make sure it is there. Never mind my comment about that then.

Regarding Symfony's convention of reverse sorting by priority vs. Drupal's convention of sorting by weight: #1825124: Provide an Drupal\EventSubscriber override that uses natural weights. Until that issue is resolved, I agree with doing what this patch does: for event listeners and things sorted in compiler passes, following Symfony's convention rather than Drupal's.

This isn't meant to test the normalizer or the encoder, just that they are registered, which is why it tests with supportsEncoding() rathe than encode(). If others agree, though, I will change the test to use encode().

I know there's some unit testing purists out there, but I think it's clearer to test normalize() and encode() rather than normalize() and supportsEncoding(), so I made that change here, along with some other minor stuff. If there's no objections to that, I think this can be RTBC.

This one simplifies the test even further to just serialize(). That's the API that matters to us. Normalizers and encoders are implementation details that I don't think need to be tested individually, since the test can only pass if all is working properly, and if there's a failure, it's not that hard to step through a debugger to find out where it is. The interdiff is relative to #18.

Code and approach look good to me too. I agree that 415 header can be a followup.I opened #1831074: Send 415 Unsupported Media Type http header when serializer encounters an unsupported format and added a link to it in the Issue Summary.

+1 from me as well. Code and comments look good.

We're slightly over thresholds atm, but this patch holds up other important stuff, and there were very smart people sprinting on it all throughout BADCamp, so...

Committed and pushed to 8.x. Thanks!

Just saw this when I git pulled:

b/core/modules/system/tests/modules/serilization_test/lib/Drupal/serialization_test/SerializationTestBundle.php

s/serilization/serialization/

could we get a quick patch to fix that?

Also doesn't this need a change notice?

There is a really little problem about the change notice: I do not have the slightest clue what are you talking about if I am just reading that notice. It badly needs a sentence or two about it is for turning an entity into JSON-LD or whatnot -- I think that's what this is about, isnt it? "One Serializer is added as a service to the DIC. This is used by controllers to process entities or arrays to their serialized equivalent." -- and what a "serialized equivalent" would be? Why do I want one, where do I use one, etc. Not to mention that 'controller' is a word noone understands yet (link to the router change notice?). This whole change notice is an enigma.

Lot better, thanks.

Same as #27, but with renames = copies.

Committed and pushed that follow-up. Thanks!