Project

General

Profile

Actions
Copy link

Task #95722

open

Why does TYPO3 have a slug-helper?

Added by Rozbeh Chiryai Sharahi over 2 years ago. Updated about 1 month ago.

Status:
Under Review
Priority:
Could have
Assignee:
-
Category:
Code Cleanup
Target version:
-
Start date:
2021-10-21
Due date:
% Done:

0%

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

Description

Hello Community,

this is just to have a general understanding of a pattern on TYPO3 code, which I do not really understand.

Since TYPO3 9 we have inhouse pretty-urls. For this, as usual these days, we have fortunately slug fields on the entities. Thank you for all this.

TYPO3 is a very mature system and it is comprehensible that we have some legacy codes here and there that look weird from today's perspective.

Now looking at the slug-helper I kind of get lost, why these kind of code-styles are still introduced on TYPO3. The slug-helper cannot be that old and at the same time TYPO3 is now enforcing dependency injection with non-public services. Therefore accessing containers and GeneralUtility::makeInstance is advised not to be done.

Well with a Helper like this it will be quite hard to obey these conventions:

$slugHelper = GeneralUtility::makeInstance(
    SlugHelper::class,
    $tableName,
    $slugFieldName,
    $fieldConfig
);

$slugHelper->generate($hereSomeArray, int $pid);
...

This way constructor injection is very hard up to not possible imho. Also it is not very intuitive to use. Why do we introduce a slug-helper in this pattern?

Imo the right way to do this would be for instance something like this:

$slugService = new SlugService();
$slugService->getGenerator($table, $fieldName)->generateByUid(int $uid)
// or
$slugService->generate($table, $fieldname, $uid)
// or 
$slugService->generate(SlugGenerateConfigurationObject)
// or
...

This is just one of many possible patterns, nevertheless this way we could

- use enforced constructor injection
- dismiss usage of general utitlity
- write tests easily by simple injection instead of registering instances on containers, ...
- understand usage simply by auto-complete

I have that feeling, that there should be some code patterns which are enforced on TYPO3 Core Code. I have this feeling, that in 5 years there will be a strong dependency on this slug-helper and there will be soon a lot of work to deprecate them.

Nevertheless I don't see exactly what kind of recommended common pattern the current implementation is following.

Please correct me with literature if I am wrong and this pattern has some advantages.

Thank you for all your great work.

Kind regards
Rozbeh Chiryai Sharahi

Actions
Copy link

Also available in: Atom PDF