[#13683] - [namespace] Move legacy controller classes to namespace
- Fixed in Code Base
- 23 Jan 2017
- Medium
- Build: 3.8.x
- # 13683
- Diff
- Digital-Peak:j3/namespace/controller
User tests: Successful: Unsuccessful:
Summary of Changes
Move JControllerLegacy to the namespace Joomla\Cms\Controller. The namespace is defined based on the decision made in Odense.
Backporting the namespaces to Joomla 3.8 will allow 3rd party extension developers to adapt their extensions to namespaces and to have the same code base for J3 and J4.
For BC an alias is registered, which can then be removed in J4 when we want to ged rid of the legacy layer. The only BC break this PR brings is that getName() on instances of JControllerLegacy will return joomla\cms\controller\ and not j anymore, so the following code outputs "joomla\cms\controller":
$controller = new JControllerLegacy();
echo $controller->getName();
The tests are not updated to use the new classes as the automated testing group is working on a plan to do real unit testing.
Testing Instructions
Load any view, they should work as before.
Documentation Changes Required
Controllers should not extend JControllerLegacy anymore, the new class will be Base in the namespace Joomla\Cms\Controller.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
| Labels |
Added:
?
|
||
| Category | Libraries | ⇒ | Administration com_content Libraries |
| Category | Libraries Administration com_content | ⇒ | Administration com_content Libraries Unit Tests |
| Labels |
Added:
?
|
||
| Category | Libraries Administration com_content Unit Tests | ⇒ | Libraries Unit Tests |
What is being gained by removing the PSR-0 autoloader support in full in 4.0 when the first version supporting PSR-4 will be 3.7?
Thought Joomla 4 should be a clean house as much as possible.
What is being gained by renaming the controller class at 3.8 and immediately dropping the alias in 4.0?
The target is that 3rd party developers can change their base code in 3 and we can get ride of legacy in J4. Also the list of alias will become quite huge and they get loaded on every single page request. So it will make sense to remove the extra load in J4. But if the community thinks we need to support the legacy layer in J4 as well, then we can keep it in place.
Right now, these couple of PRs look to me as "we want to dump some stuff in 4.0 but we don't have the code in 3.x to do it right now so let's quickly add these things so we can dump it".
Ya it's a little bit of technical debt, but I don't see the major issue with continuing to support the PSR-0 autoloader through the 4.0 series or continuing to have JControllerLegacy aliased to the namespaced variant for the same period. It's low overhead on us but keeps the number of absolute breaking changes down so it's keeping extension developers a little less annoyed too.
I'm not against moving forward, but right now I feel like the approach is "if you want to write 3.x and 4.x compatible code, 3.8 is going to be the first version you'll be able to do this for because we're going to add the compatibility layers in that release and remove them all in 4.0". It feels like too short of a transition period for no other reason than to get rid of some technical debt pretty quickly.
| Category | Libraries Unit Tests | ⇒ | External Library Libraries Unit Tests |
| Labels |
Added:
?
|
||
Please update your Composer install. What's in the repo now uses Composer 1.3, it looks like you've still got 1.2.
if you want to write 3.x and 4.x compatible code, 3.8
The only concern I have is that we have maintain then legacy layer in J4 on many other places just because we are afraid to drop it in J4. This will make the code very complex. On some point we have to make the cut. From my experience people started to update their Joomla site very regularly to be on the latest Joomla.
Well, it depends what the legacy layer is. Right now we're just talking a single method in our autoloader and some class aliases with these pull requests. I don't think that's a major ask personally. Obviously the stuff like what's happening with the JLayout proposals and file/class structures for the MVC layer has a lot more code impact and needs more discussion/review and has more implications on a legacy layer.
| Title |
|
||||||
| Title |
|
||||||
wilsonge
- | Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-23 15:52:35 |
| Closed_By | ⇒ | wilsonge |
The alias should persist during the 4.x lifetime. IMO some of the PRs coming out of this weekend are creating too short of a deprecation period for creating code that can support both 3.x and 4.x.
What is being gained by removing the PSR-0 autoloader support in full in 4.0 when the first version supporting PSR-4 will be 3.7?
What is being gained by renaming the controller class at 3.8 and immediately dropping the alias in 4.0?