Introduce a mutable HTML fragment interface

Here is one possible implementation. I'm not totally sold on this, though :

• the setter methods return $this, for a fluent interface, but :
  • this is not actually used by callers of these methods
  • within the mutable interface, $this makes little sense : the returned implementation is used for both its mutable and immutable interfaces, so which one should be returned ?
• there is only one function (yet ?) in which it has been possible to use this interface instead of the concrete class : in all other cases, the methods are invoked on a locally create concrete Page or Fragment

But at least it seems to work.

@dawehner : yes, that would obviously be a tempting choice, but then it would violate the basic principle of interface segregation.

I do not see how this change can break the TermTranslationFieldViewTest, though. Especially as it passes on my machine. Bot fluke ?

Rerolled accordingly. This turned out to allow more extensive use of the interface. Let's see if it breaks any tests.

1. +++ b/core/lib/Drupal/Core/Page/HtmlMutableFragmentInterface.php
   @@ -0,0 +1,80 @@
   + * Mutator interface for the domain object for a portion of an HTML page, including related data.
   

   80 chars. :-( We can probably just drop everything after the comma.

2. +++ b/core/lib/Drupal/Core/Page/HtmlMutableFragmentInterface.php
   @@ -0,0 +1,80 @@
   + * Related data includes any additional information relevant to a fragment of
   + * HTML that would not be part of the HTML string itself. That includes, for
   + * example, required CSS files, Javascript files, link tags, meta tags, and the
   + * title of a page or page section.
   

   We don't need to repeat this from the parent interface.

3. +++ b/core/lib/Drupal/Core/Page/HtmlMutableFragmentInterface.php
   @@ -0,0 +1,80 @@
   + * @ingroup menu
   

   Er, no?

Just doc fixes, easy to address. Then we're good here.

Rerolled accordingly. Actually, there was an actual earlier bug : a reference to Title::CHECK_PLAIN without its namespace, so I added it too.

Unless bot disapproves. Thanks, fgm!

The single test which fails on the bot passes on my machine, and does not seem related to the patch in any way. This looks like a bot fluke to me : can anyone triple check ? It was not possibly to check it on simplytest.me, because displaying the testing page eats more than the 256 MB allocated to test instances, even with the minimal profile.

Looks like it passed again. Bot fluke.

#2352155: Remove HtmlFragment/HtmlPage will remove HtmlFragment/HtmlPage for now. Some of the concepts could be re-introduced in 8.1.x or later if we can find use cases. Moving to 8.1.x/postponed for now.

Which is probably more likely to be baby steps towards #1843798: [meta] Refactor Render API to be OO.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Wanted to bump one more time before closing.

This is long obsolete since #2352155: Remove HtmlFragment/HtmlPage, the ideas from there have not returned, let's close this out.