Change Details

Status quo: WikiPage::prepareContentForEdit() provides access to PST-transformed and rendered content for pre-save or post-save processing. It uses a kind of home-brew memoization mechanism to allow callbacks to access this information while a new revision is being saved, without having to re-generate it. The PreparedEdit object returned by prepareContentForEdit() is not sufficient for multi-content revision handling. Also, several fields exposed by it seem to be unused, or and/or have unclear semantics. A better mechanism is needed to provide (cached?) access to PST content and rendered ParserOutput each slot, as well as a ParserOutput containing the combined rendering of all slots. Ideally, callbacks would receive a provider object as a parameter which facilitates lazy creation and caching. A first attempt to cover the described functionality can be found in the DerivedPageDataUpdater class proposed in <https://gerrit.wikimedia.org/r/c/405015/>. However, a more narrow interface should be exposed to calling code, and WikiPage should (eventually) no longer server as the factory and in-situ-cache for the provider object.

Status quo: WikiPage::prepareContentForEdit() provides access to PST-transformed and rendered content for pre-save or post-save processing. It uses a kind of home-brew memoization mechanism to allow callbacks to access this information while a new revision is being saved, without having to re-generate it. The PreparedEdit object returned by prepareContentForEdit() is not sufficient for multi-content revision handling. Also, several fields exposed by it seem to be unused, or and/or have unclear semantics. A better mechanism is needed to provide (cached?) access to PST content and rendered ParserOutput each slot, as well as a ParserOutput containing the combined rendering of all slots. Ideally, callbacks would receive a provider object as a parameter which facilitates lazy creation and caching (see T194049). A first attempt to cover the described functionality can be found in the DerivedPageDataUpdater class proposed in <https://gerrit.wikimedia.org/r/c/405015/>. However, a more narrow interface should be exposed to calling code, and WikiPage should (eventually) no longer server as the factory and in-situ-cache for the provider object.

Status quo: WikiPage::prepareContentForEdit() provides access to PST-transformed and rendered content for pre-save or post-save processing. It uses a kind of home-brew memoization mechanism to allow callbacks to access this information while a new revision is being saved, without having to re-generate it. The PreparedEdit object returned by prepareContentForEdit() is not sufficient for multi-content revision handling. Also, several fields exposed by it seem to be unused, or and/or have unclear semantics. A better mechanism is needed to provide (cached?) access to PST content and rendered ParserOutput each slot, as well as a ParserOutput containing the combined rendering of all slots. Ideally, callbacks would receive a provider object as a parameter which facilitates lazy creation and caching (see T194049). A first attempt to cover the described functionality can be found in the DerivedPageDataUpdater class proposed in <https://gerrit.wikimedia.org/r/c/405015/>. However, a more narrow interface should be exposed to calling code, and WikiPage should (eventually) no longer server as the factory and in-situ-cache for the provider object.