Project

General

Profile

Actions

Feature #97264

open

ext_localconf.php architecture with namespaces

Added by Gabriel Kaufmann / Typoworx NewMedia about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2022-03-31
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

I noticed from TYPO3 v11 there is an updated best-practice architecture for handling with ext_localconf.php. I'm referring to this document:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/ConfigurationFiles/Index.html

Mentioning NOT to use global namespaces to avoid namespace nesting. This is correct, but I think it would be a better approach to use classified namespaces for the extension vendor/extension key:

like this:

<?php
namespace My\FooBarExt {
  use TYPO3\CMS\Core\Utility\VersionNumberUtility;
  use TYPO3\CMS\Core\Utility\ExtensionManagementUtility;

  defined('TYPO3_MODE') || die('Access denied.');

  (function ($extKey) {
    // ... here is what usually is inside ext_localconf.php
  })('my_foobar_ext');
}

I would much more favor to replace ext_localconf.php with a Package-Registration File/Class that looks like those one used in Symfony or Laravel Packages being able to configure f.e. Site YAML (site-package config & extension routes) and services provided by the package.

This would follow more the new approach to go with Symfony/HTTP-Foundation coding standards. Here's an example for a ServiceProvider from laravel which I really like for how it is handling package (aka extension) registration:

https://laravelpackage.com/03-service-providers.html#creating-a-service-provider

Please drop me some constructive feedback. Please let me know if there are plausible reasons NOT to use any php namespace wrapping in ext_localconf.php or is this only meant for the global "namespace {}" without classified name?

Actions

Also available in: Atom PDF