Bug #55830: Cleanup mess with treeView implementations
Rename classes with the same name
We have 3 implementations of the \localPageTree class in the global namespace in:
We should clean this up, as it's quite confusing for the developer which class is used when and makes autoloading impossible.
I attach Sequence diagram for db_new.php (and a source code of it). Diagram was generated with http://interactive.blockdiag.com/seqdiag/
For the class inheritance diagram see http://forge.typo3.org/issues/55830
[TASK] Rename classes with the same name
We have 3 implementations of the \localPageTree
class in the global namespace:
This patch renames classes from db_new and move_el files.
It should not break non core scripts, as both db_new.php
and move_el.php are entry points, so classes defined
there should only be used in the entry point scope.
The class 'localPageTree' from the class.browse_links.php
will keep its name, so it can be added to autoload now.
Reviewed-by: Markus Klein
Reviewed-by: Alexander Opitz
Tested-by: Alexander Opitz
Reviewed-by: Stefan Neufeind
Tested-by: Stefan Neufeind
#5 Updated by Tymoteusz Motylewski over 6 years ago
Before the patch it worked like that:
- PagePositionMap always created getInstance("localPageTree") object for tree rendering.
- there were multiple implementations of the localPageTree object in different files.
- none of them were registered in the autoloader.
- so depending on the entry point script, different class was loaded (from db_new.php, move_el.....)
- so at the end PagePositionMap created different 'localPageTree' classes, depending on the entry point