Epic #85990

Extbase CommandControllers vs. Symfony/Console Integration

Added by Benni Mack about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2018-08-27
Due date:
% Done:

100%

Sprint Focus:

Description

With Symfony's quasi-default package symfony/console in PHP, TYPO3 now still contains two ways (Extbase Command Controllers and Symfony Console Commands), irritating developers what the best strategy for the future is.

Current benefits of Extbase Command Controllers
- Use full feature-set of Extbase's under-the-hood framework like our custom Extbase dependency injection and custom annotation functionality
- Use multiple commands within one controllers, which can be related
- Automatically mapping of command line arguments

Current downsides of Extbase Command Controllers
- Registration in ext_localconf.php together with everything else, which makes it impossible to fetch information about command controllers without having to load all ext_localconf.php
- Magic naming convention of ExtensionName/MyCommandController->customCommand which maps to extensionname:my:custom and possibly reducing it to "my:custom" but makes it hard to override commands from another place and to overcome naming clashes.
- Output: Uses a wrapper around base features of Symfony Console, with only very limited functionality with custom API on top, where this layer would be better to use symfony/console (SymfonyStyle) directly
- No maintenance in years to overcome conceptual flaws like fetching configuration from TypoScript (which is based on the first pagetree with sys_template record) basically making it hard to developers to e.g. manually map settings for persistence into the CLI context of Extbase.

Current benefits of Symfony/Console integration
- Allows to integrate all features for defining validating input arguments/options
- Output is flexible by default, allowing to custom functionality like tables natively
- Separate registration of Commands in one place
- Integration is built so no DB connection or initialized backend user is necessary, to fetch all configuration for a command (now possible with Extbase too, but with some conceptual issues for loading pagetrees and configuration).
- All features for using Symfony/Console functionality is integrated.

Current downside of Symfony/Console integration
- Missing section in Core APIs on how to use Symfony/Console within TYPO3 (added to docs.typo3.org Core APIs).
- No possibility to add symfony commands in scheduler (added in 9.0)
- No special treatment for Commands which should be excluded from scheduler (Extbase has @cli and @internal)
- No documentation on how to use Extbase DI or repositories/domain models with configuration within a Symfony/Console command
- No listing of available commands in the TYPO3 Backend ("Configuration")

On top, TYPO3 Core still uses both approaches. This is very confusing for extension maintainers and newbies.

There needs to be a decision which direction CLI should continue, and a full migration path should be available.


Subtasks

Feature #85991: Allow symfony commands to be non-schedulableClosedBenni Mack

Task #85996: Migrate EM CommandController to symfony/commandClosedBenni Mack

Feature #86001: Move workspaces scheduler tasks to native symfony commandsClosedBenni Mack


Related issues

Related to TYPO3 Core - Bug #82390: Migration of Extbase command controllers breaks scheduler functionality Closed 2017-09-08
Related to TYPO3 Core - Task #85977: Deprecate @cli annotation Closed 2018-08-25

History

#1 Updated by Benni Mack about 1 year ago

There is even a third component playing into that:

EXT:scheduler with custom scheduler tasks

scheduler is a GUI but also the functionality provide to define tasks that should be run on CLI (but also other states). This actually mixes a state where both definition of when things are run and the execution context play a role. In general CLI scripts should never be called in backend context, as an admin user has different settings than the CLI user, possibly leading to different results.

The end goal needs to be: One solution with the least drawbacks while providing as much functionality as all three parts play.

A common end scenario could be:
- Have only symfony/console commands
- Use scheduler UX to define scheduling times and to take care of scheduling
- Run everything in CLI context (even though a Backend UI could schedule a task/command to run at next run)

#2 Updated by Benni Mack about 1 year ago

  • Description updated (diff)

#3 Updated by Benni Mack about 1 year ago

  • Description updated (diff)

#4 Updated by Benni Mack about 1 year ago

  • Related to Bug #82390: Migration of Extbase command controllers breaks scheduler functionality added

#5 Updated by Benni Mack about 1 year ago

  • Related to Task #85977: Deprecate @cli annotation added

Also available in: Atom PDF