Project

General

Profile

Actions

Epic #85990

closed

Extbase CommandControllers vs. Symfony/Console Integration

Added by Benni Mack over 5 years ago. Updated about 4 years ago.

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

100%

Estimated time:
(Total: 0.00 h)
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 3 (0 open3 closed)

Feature #85991: Allow symfony commands to be non-schedulableClosedBenni Mack2018-08-27

Actions
Task #85996: Migrate EM CommandController to symfony/commandClosedBenni Mack2018-08-27

Actions
Feature #86001: Move workspaces scheduler tasks to native symfony commandsClosedBenni Mack2018-08-28

Actions

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #82390: Migration of Extbase command controllers breaks scheduler functionalityClosedAlexander Schnitzler2017-09-08

Actions
Related to TYPO3 Core - Task #85977: Deprecate @cli annotationClosedAlexander Schnitzler2018-08-25

Actions
Related to TYPO3 Core - Task #86089: Document scheduler tasks based on symfonyClosed2018-09-02

Actions
Actions #1

Updated by Benni Mack over 5 years 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)

Actions #2

Updated by Benni Mack over 5 years ago

  • Description updated (diff)
Actions #3

Updated by Benni Mack over 5 years ago

  • Description updated (diff)
Actions #4

Updated by Benni Mack over 5 years ago

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

Updated by Benni Mack over 5 years ago

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

Updated by Henri Nathanson over 4 years ago

+1 .. add docu about repository usage/injection; drop EXT:scheduler own task definitions/deprecate them; possibly add better configuration support with EXT:scheduler for commands configuration (parameters)

Actions #7

Updated by Georg Ringer about 4 years ago

  • Status changed from New to Closed

closed as all subissues are solved

Actions #8

Updated by Susanne Moog about 4 years ago

  • Related to Task #86089: Document scheduler tasks based on symfony added
Actions

Also available in: Atom PDF