Feature #69181

CommandController validator

Added by Guy Couronné about 5 years ago. Updated over 2 years ago.

Could have
Target version:
Start date:
Due date:
% Done:


PHP Version:
Sprint Focus:



Version : TYPO3 CMS 6.2.14

In Scheduler, I create a Task extending extbase/task (\TYPO3\CMS\Extbase\Scheduler\Task) with a progress bar (\TYPO3\CMS\Scheduler\ProgressProviderInterface) and an extbase/additionalFieldProvider (\TYPO3\CMS\Extbase\Scheduler\FieldProvider). In it, I call MemberCommandController->synchroniseMailChimpCommand. For avoiding a memory limit crash, I use a variable called $limit, to limit the number of members synchronised for each execution of the task.
As $limit is a argument of the task (as the memory is depending on the host machine), I would like to validate if it's an integer not empty (for avoiding "xyz" or "0" as limit).
However, I didn't find, in CommandController (\TYPO3\CMS\Extbase\Mvc\Controller\CommandController), any validatorResolver (\TYPO3\CMS\Extbase\Validation\ValidatorResolver), as has AbstractController (\TYPO3\CMS\Extbase\Mvc\Controller\AbstractController).

I would like to know if it could be implemented direclty into the core (into CommandController or into another class like ValidatorCommandController) or if it's up to me to add this ?

Thank you.


#1 Updated by Susanne Moog almost 3 years ago

  • Category set to scheduler

#2 Updated by Benni Mack over 2 years ago

  • Status changed from New to Rejected

In terms of Extbase Command Controllers it is possible to add your own validators. TYPO3 Core does not plan to extend this functionality, but rather switch to Symfony Console Commands, as there are lots of conceptual issues with the current Extbase Command Controller approach (like initialization of a request object, validating "pseudo-deterministic" root page ID for fetching TypoScript configuration).

Additionally, Scheduler itself has a lot of conceptual issues, mainly currently the functionality of a task serialized to the DB, and custom HTML to be written from the FieldProvider directly. This has to be refactored as well, in a broader scope. Don't know if this will happen for the current development cycle.

Hope this clears your issue up.

Sorry for the late reply, just randomly stumbled on this ticket, and saw that it was 2 years old already. Really sorry about the lack of feedback.

Also available in: Atom PDF