Add a _entity_view routing default for viewing an entity

Empty patch

+++ b/core/lib/Drupal/Core/Entity/Controller/EntityViewController.phpundefined
@@ -0,0 +1,66 @@
+  public function view(EntityInterface $entity, $view_mode, $langcode = NULL) {
+    return $this->entityManager
+      ->getRenderController($entity->entityType())
+      ->view($entity, $view_mode, $langcode);
+  }

Having $langcode here seems useless, when you can't set it?

I'd rather either set the langcode to anguageManager->getLanguage(Language::TYPE_CONTENT)->id or actually just get the corresponding translation ($entity->getTranslation(.. content langcode..) if $entity implements the TranslatableInterface and hasTranslation (content langcode).

You want to check with @plach what makes sense. But I think we want to get deprecate $langcode arguments in favor of passing the right entity translation around. But I guess we can't actually remove those arguments anymore?

+++ b/core/lib/Drupal/Core/Entity/Enhancer/EntityRouteEnhancer.phpundefined
@@ -47,6 +47,15 @@ public function enhance(array $defaults, Request $request) {
+        // Set by reference so that we get the upcast value.
+        $defaults['entity'] = &$defaults[$entity_type];

This works in most cases, but what happens if you have specified a different variable name? See entityConverter

+++ b/core/modules/system/lib/Drupal/system/Tests/Entity/EntityViewControllerTest.phpundefined
@@ -0,0 +1,63 @@
+class EntityViewControllerTest extends WebTestBase {

Is there a specific reason why you haven't wrote a unit test?

awesome idea. let the scope of patch focus on route and probably language for follow-up

Just to note, this will certainly break when #1943846: Improve ParamConverterManager and developer experience for ParamConverters is done.

#9: _entity_view-2040265.9.patch queued for re-testing.

It didn't break because it just adds onto EntityRouteEnhancer instead of adding a new top level one.

This blocks a half dozen conversions in #1971384: [META] Convert page callbacks to controllers, which is a critical, so this is as well.
(Think /node//%, user/%, etc)

+++ b/core/lib/Drupal/Core/Entity/Enhancer/EntityRouteEnhancer.phpundefined
@@ -47,6 +48,29 @@ public function enhance(array $defaults, Request $request) {
+          $defaults['entity'] = &$defaults[$entity_type];
...
+              $defaults['entity'] = $defaults[$flipped[$entity_type]];

Why do only set be reference in the first instance?

+++ b/core/lib/Drupal/Core/Entity/Enhancer/EntityRouteEnhancer.phpundefined
@@ -47,6 +48,29 @@ public function enhance(array $defaults, Request $request) {
+          // The entity is not keyed by its entity_type. Attempt to find it
+          // using a converter.
+          $route = $request->attributes->get(RouteObjectInterface::ROUTE_OBJECT);
+          $options = $route->getOptions();
+          if (isset($options['converters'])) {
+            $flipped = array_flip($options['converters']);
+            if (isset($flipped[$entity_type]) && !empty($defaults[$flipped[$entity_type]])) {
+              $defaults['entity'] = $defaults[$flipped[$entity_type]];
+            }
+          }

And do we have any test coverage of this code?

Why default value is not bound to 'default'? For the most of cases we will use default view mode of entity assuming it's full
1) do we need conversion of default to full as defaults?
2) do we need tests for that too?

+++ b/core/lib/Drupal/Core/Entity/Enhancer/EntityRouteEnhancer.phpundefined
@@ -47,6 +48,46 @@ public function enhance(array $defaults, Request $request) {
+        $defaults['view_mode'] = $view_mode;
+        unset($defaults['_entity_view']);

what is a dafults for now? full/default

related: #2006348: Remove default/fallback entity form operation

Yes, I suppose this needs fallback to 'default' view mode

Discussed in IRC - the route should use 'full' because it's default in EntityRenderControllerInterface::view()
Also it would be great to have tests for none-existent view mode

+++ b/core/lib/Drupal/Core/Entity/Controller/EntityViewController.phpundefined
@@ -0,0 +1,68 @@
+  public function view(EntityInterface $_entity, $view_mode, $langcode = NULL) {

so $view_mode needs 'full' as default

+++ b/core/lib/Drupal/Core/Entity/Enhancer/EntityRouteEnhancer.phpundefined
@@ -47,6 +48,46 @@ public function enhance(array $defaults, Request $request) {
+        $defaults['view_mode'] = $view_mode;

Or maybe $defaults['view_mode'] = empty($view_mode) ? 'full' : $view_mode;

+++ b/core/tests/Drupal/Tests/Core/Entity/Enhancer/EntityRouteEnhancerTest.phpundefined
@@ -62,6 +63,41 @@ public function testEnhancer() {
+    $defaults['_entity_view'] = 'entity_test.default';

this uses 'default' view mode that does not exists

Ah, that last interdiff is interesting :)
The changes in #27 look good to me, as do the ones before that.

+1 tortbc

Committed 1deffa8 and pushed to 8.x. Thanks!

Similar to https://drupal.org/node/1799642 I think we need a change notice.

Sweet - so, isn't there some existing code in HEAD that can be removed now ?

oh, d.o ...

@yched, issues like #1987898: Convert user_view_page() to a new style controller can now use this.

Don't think it's necessary to put in a whole entity annotation? Should be enough to just say given you have an entity type named whatever?

Can we maybe put in an example of how you'd do it in 7.x?

+++ b/core/lib/Drupal/Core/Entity/Controller/EntityViewController.php
@@ -0,0 +1,69 @@
+   * @param \Drupal\Core\Entity\EntityInterface $_entity
+   *   The Entity to be rendered. Note this variable is named $_entity rather
+   *   than $entity to prevent collisions with other named placeholders in the
+   *   route.
...
+  public function view(EntityInterface $_entity, $view_mode = 'full', $langcode = NULL) {

I don't want to argue in favor of rolling this back or anything, but I just want to note that using the underscore in this way sort of conflicts with the fact that we use the underscore to separate magic attributes like '_account' from actual route parameters. I brought that up there and was told that prefixing arguments with underscores is so far-fetched we shouldn't worry about it. For instance if we were to introduce a menu_get_object()-style '_entity' attribute for routes where it would make sense, this would break.
I don't want to open a whole discussion about this or the (arguably poor) use-case, I just wanted to point out that this is less than ideal.
I also don't have a better suggestion, however.

Actually... wha? Why is that property $_ prefixed? That doesn't make sense at all...

same reason it's $_content, $_controller, $_form, $_entity_list...

EDIT: I misread the question, I thought it was about $_entity_view. If you look in EntityRouteEnhancer::enhance(), there is a whole section on normalizing what the entity is.

If you have /foo/{account} to mean the User entity type, it has to use converters to figure that out. I'm not 100% sure why that's done here, or why we don't turn it back into the named param you specify at the end.