Follow-up from #2218117: Bring back metatag support for the HtmlPage object.
Problem/Motivation
HtmlFragment is a good first step, but to really drive it forward we should turn it into an interface.
Proposed resolution
That is, we need an interface that represents a page fragment or block, whose methods provide *read only* access to the content and metadata of that fragment. The starting point for that (and for the purposes of this issue, the ending point) is the getter methods of HtmlFragment.
The goal is to get to the point that Block plugins can implement this interface directly, which means that, to the page rendering pipeline it simply has one fragment/block interface object from the controller and a bunch of others that it got from the blocks system (or whatever layout tool, that's off topic)
This issue is mostly a moving-code-around issue, not a new-functionality-creating issue.
Remaining tasks
Possible names for this interface: HtmlFragmentInterface, BlockInterface. Discuss.
API changes
HtmlFragment implements the interface defined here.
For follow-up: Block plugins implement this interface, too. NOT for this issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | interdiff.txt | 682 bytes | Crell |
| #19 | 2256373-fragment-interface.patch | 7.31 KB | Crell |
Comments
Comment #1
Crell commentedComment #2
Crell commentedKISS. This should have no functional changes, just moving stuff around.
Comment #3
Crell commentedSee also: #2267843: Split off CacheableTrait
Comment #4
dawehnerWe should explain what sideband data means in this context.
ups
Comment #5
Crell commentedAddresses #4.
Comment #6
sunMakes sense and looks almost ready to me; just some minor things:
We've lost the phpDoc on the class?
"A generic HTML fragment."
?
The order of methods on the interface looks quite random right now. Can we re-order them?
To my knowledge, we're not following PSR-5 (yet) and still using fully qualified resource names.
Comment #7
Crell commented1 and 3 are artifacts of PHPStorm's refactor command. Corrected.
For point 2, the order was, I think, the order that those methods are in HtmlFragment. Meh. I've reordered them to something that I think makes sense, but let's not bikeshed that. I did not rearrange anything in HtmlFragment so as to not create unnecessary patch jitter.
Comment #8
sunThanks!
Comment #9
catchWhat's wrong with ['#cache']['tags']?
Otherwise looks OK.
Comment #10
Crell commentedNothing. Just an editing quirk.
Freshly rebased patch attached.
Comment #11
sunComment #12
joelpittetJust removing the default.settings.php change that got added in there and a minor whitespace.
RTBC++
Comment #13
alexpottIs sideband data used anywhere else to mean this? Google didn't turn up anything useful.
Comment #14
Crell commentedI don't know that there is a standard collective term for "that sort of stuff". "Sideband", I believe, comes from the telecomm industry and refers to information sent in "gaps" in the audio signal, mostly control information and is also where SMS messages live. (It's complicated audio frequency mechanics I don't fully understand.)
If there's a better name for that please suggest it, but please please don't bikeshed this simple issue on that as it's blocking at least 2 other issues at the moment. It's just in a comment so has no API impact.
Comment #15
alexpottUsing a term in a way that is not been used before and a term that you admit to not fully understanding in our documentation and me pointing this out is not bikeshedding. Documentation exists to add clarity and help humans interpret what something does. Semantically extending sideband for Drupal is probably not the way to go. You are not sending any information in the gaps.
Like is anything lost by changing "sideband" to "related" or "additional". For example,
"and so on" - this is very vague, we should be a bit more precise here.
Comment #16
catchAlso
<head>elements are HTML, so it's not "non-HTML".We could possibly use 'additional page-level data and assets' - the important thing to convey is that these are things which have to be applied to the page as it's rendered as a whole, as opposed to the specific fragment.
Comment #17
Crell commentedTrying again on the comment... No interdiff because nothing changed other than that one docblock, which was a total rewrite.
Comment #18
dawehnerAnd you really think that typing that sentence was less effort than just creating the interdiff?
Given that we consider using an html fragment as sort of main entry point for modules like metatag I doubt we want to have a immutable interface,
or at least we should really explain why we want to do that, beside of functional programming purity.
It is confusing to use OR, AND seems more appropriate tbh.
Comment #19
Crell commented1. ... Functional programming purity has nothing to do with it. We want to be able to use this interface for blocks, too. Those will be returning the various related stuff they require via those methods, but the data won't come from setters but from whatever logic exists inside that class. That makes setters inappropriate for the base interface. (HtmlFragment the class still has them, of course, and I suppose if we really want we could add an interface for the setters for HtmlFragment to use as well but that's for another issue.)
2. As a native English speaker I don't see much difference here between and/or, but.. meh.
(Can we please get this committed before we reach the 3 WEEK mark for just splitting off an interface?)
Comment #20
dawehnerto quote you: I am so out of things
Comment #21
alexpottCommitted 008bf08 and pushed to 8.x. Thanks!
Reflowed comment on commit