Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[TASK] Use ServerRequestInterface in EditDocumentController
A controller reads information from the request object and creates
and returns a response object.
Backend controllers in TYPO3 however have a history of being messy:
They read information from GET/POST using these super globals
directly, or by calling helper methods like _GP(), getIndpEnv()
and others.
Some controllers don't even return a response object to be further
processable by PSR-15 middlewares, but call stuff like
HttpUtility::redirect() to write a response and die.
Furthermore, especially the old and most important backend
controllers have tons of public properties and methods. This makes
refactoring towards good controller code hard. But controllers
shouldn't expose much public API: They usually should not be called from
outside, except their main entry methods that take the request object
in order to turn it into a response object. Everything else should be
protected and used internally only.
The patch takes EditDocumentController as one of the most complex
and important backend controllers and refactors it:
* (Nearly) all methods and properties are protected.
* All request dependant data is read from $request->getParsedBody(),
$request->getQueryParams() or $request->getAttribute('serverParams').
This patch is very careful and tries to be fully backwards compatible in
v9. In case some extension still uses properties or methods of this
controller, a series of different strategies have been used to retain
compatibility:
* Properties made protected use PublicPropertyDeprecationTrait
to trigger_error() if accessed.
* Nearly all properties are kept, keep their state and type to not
break a possible 3rd party usage.
* Nearly everything made protected or deprecated is configured to be
scanned by extension scanner, except a couple of properties that
would create too many false positives. Those are marked as not scanned
in the deprecation ReST file.
* Various methods need $request now. They are always called with that
argument, but fall back to $GLOBALS['TYPO3_REQUEST'] and
trigger_error() if not given.
* Some methods are kept with their old signature as public and are
set to deprecated, but trigger_error() to then call a new protected
method with a better name and a more strict sigature.
* Some methods are kept public in v9, but test if they were called from
outside to then trigger_error() telling they will be set to protected
in v10.
* A couple of properties still must be public since other core
functionality reads from them directly. Those are marked with
an @todo and @internal to have freedom in v10 for further cleanup.
* Some (non core) hooks or signals may now trigger deprecation log
entries if they try to set properties or call methods. Those need
detailed handling later and may hand over specific properties instead
of full "pObj". This will be a topic later if the main signal/hook
handling gets more love. As a general alternative, some hooks or signal
usages could also be turned into a PSR-15 middleware instead. In case
of EditDocumentController, the write access of the two existing signal
may eventually be removed altogether later, since an existing slot
could probably better achieve the same job by being converted into a
middleware that manipulates $request if it needs to write.
Changing controllers this way gives the core much more freedom
to refactor and significantly improve controller code in v10, after
now deprecated code from patches like these have been removed.
Change-Id: I3527c43c52f6e738f34ac0a21efc1ac904a3f6d2
Resolves: #84195
Releases: master
Reviewed-on: https://review.typo3.org/56018
Tested-by: TYPO3com <no-reply@typo3.com>
Reviewed-by: Susanne Moog <susanne.moog@typo3.org>
Tested-by: Susanne Moog <susanne.moog@typo3.org>
Reviewed-by: Frank Naegler <frank.naegler@typo3.org>
Tested-by: Frank Naegler <frank.naegler@typo3.org>- Loading branch information
