Available serialization formats

Idea we discussed today on the REST Team call:

1) In the compiler pass, build up a list of available formats and stick it in a container parameter. Then we can just grab that list from the container (and can do it via injection, too, rather than needing the actual container passed to us).

2) Make each format its own serializer. So we register a serializer.jsonld, a serializer.atom, a serializer.svg, and whatever other formats. Then you can enable or disable different serializers for different paths very easily.

DAMNIT FIREFOX!

1) In the compiler pass, build a list of formats and stick it into a container parameter. Then we can access that list via the container easily. We can even have it injected.

2) Register each format as a separate service. So we get serializer.jsonld, serializer.atom, serializer.svg, etc. That makes it easier to wire up different serialization formats for different paths based on user configuration.

DAMNIT DRUPAL!

Is this as easy as grabbing the encoders from this line of code and storing them in the container, then building a form off that for configuration options?

<?php
    foreach ($container->findTaggedServiceIds('encoder') as $id => $attributes) {
      $priority = isset($attributes[0]['priority']) ? $attributes[0]['priority'] : 0;
      $encoders[$priority][] = new Reference($id);
    }
?>

(code taken from http://drupalcode.org/project/drupal.git/blob/9e28980b6f5e1ca6273cd93a7f...)

Almost. You wouldn't build an array of Reference objects but of either the service IDs or the name of the format, or maybe an associative array of that, or whatever it is klausi says he needs. But either way it would be a PHP primitive structure, no objects. Then you'd assign that to the container with $container->setProperty().

Just referencing #1819760: Add a REST export display plugin and serializer integration. here, I think this could be useful for that.

Should this patch also include the regular JSON/AJAX stuff that got in too? #1846000: Add serializer support for JSON and AJAX

Changed the tag to format_info and added one for the json encoder.

format_info is still too generic. That could mean any number of things. The tag should probably be namespaced. (Are dots legal in tags?)

That said, why do we need a separate tag at all? Why can't it just be attributes on the encoder tag?

Yeah, that makes alot of sense, and encoder is exactly what it is.

#15: 1850704-15.patch queued for re-testing.

Looks simple enough

#22 looks good to me, too.

This fails again because #1854874: Add serializer support for XML got reverted. Could wait for that?

Back to RTBC

Yep, this looks good now. Let's get this in. This will be useful for views related issues.

Committed to 8.x. Thanks!