Add PageSubjectsLookup for page-level subject predicates#795
Draft
JeroenDeDauw wants to merge 1 commit intomasterfrom
Draft
Add PageSubjectsLookup for page-level subject predicates#795JeroenDeDauw wants to merge 1 commit intomasterfrom
JeroenDeDauw wants to merge 1 commit intomasterfrom
Conversation
`pageHasMainSubject` and `pageHasSubjects` previously lived on `ViewHtmlBuilder`, even though neither rendered any HTML. Reaching them via `newViewHtmlBuilder()` forced consumers (the internal hook code, and external code such as #781's RedHerb sidebar) to traverse a factory named after view-HTML construction to ask a domain question. `SubjectContentRepository` was rejected as a destination: `SubjectContent` is a MediaWiki `JsonContent` slot wrapper, a persistence detail not in the glossary, and the predicates take/return only domain types. Introduce `Application/PageSubjectsLookup`, a small concrete class that depends on the existing `SubjectRepository` interface and exposes the two predicates against `PageId`. Both are one-line delegates to `PageSubjects::hasSubjects()` / `hasMainSubject()`. Add `PageSubjects::hasMainSubject()` to mirror the existing `hasSubjects()` predicate and dedup the recurring `getMainSubject() !== null` check. Drop the predicates from `ViewHtmlBuilder` and remove their tests; the behavior is now covered by `PageSubjectsLookupTest`. Addresses one of the two breach points raised in #789. The other (`NeoWikiHooks::addNeoWikiModules` called from a foreign extension's SpecialPage) lives on the `frontend-extensibility` branch and will follow up after #754 lands.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For #789
pageHasMainSubjectandpageHasSubjectspreviously lived onViewHtmlBuilder, even though neither rendered any HTML. Reaching them vianewViewHtmlBuilder()forced consumers (the internal hook code, and external code such as #781's RedHerb sidebar) to traverse a factory named after view-HTML construction to ask a domain question.SubjectContentRepositorywas rejected as a destination:SubjectContentis a MediaWikiJsonContentslot wrapper, a persistence detail not in the glossary, and the predicates take/return only domain types.Introduce
Application/PageSubjectsLookup, a small concrete class that depends on the existingSubjectRepositoryinterface and exposes the two predicates againstPageId. Both are one-line delegates toPageSubjects::hasSubjects()/hasMainSubject().Add
PageSubjects::hasMainSubject()to mirror the existinghasSubjects()predicate and dedup the recurringgetMainSubject() !== nullcheck.Drop the predicates from
ViewHtmlBuilderand remove their tests; the behavior is now covered byPageSubjectsLookupTest.Addresses one of the two breach points raised in #789. The other (
NeoWikiHooks::addNeoWikiModulescalled from a foreign extension's SpecialPage) lives on thefrontend-extensibilitybranch and will follow up after #754 lands.Doesn't claim to close #789 — that issue's broader question of whether NeoWiki should commit to a documented PHP API surface is unresolved on the issue thread.