Project

General

Profile

Actions
Copy link

Task #103071

open

Trying to render backend/fluid T3-Link, but LinkHandler concept is kind of weird as there is no real parser for t3links into table/uid parts

Added by Gabriel Kaufmann / Typoworx NewMedia 7 months ago. Updated 7 months ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2024-02-07
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.2
Tags:
backend, fluid-viewhelper, linkhandler
Complexity:
Sprint Focus:

Description

I came to the conclusion that LinkHandler concept looks kind of weird.

I basically wanted to code my own Content-Element Backend Preview and came across the problem that I wanted to display a t3link as Linked Record with icon (edit-link to the backend record for given uid). I know this basically sounds crude, but obviously this is not really comfortable possible.

Initially I thought there is something like this BE/Fluid ViewHelper:
<be:uri.editRecord uid="42" table="a_table" returnUrl="foo/bar" />

But it can't handle t3-links on it's own.

Okay let's try to split the t3link, say it's:
t3://page?uid=24

We have type page and uid 24. Ok sounds simple, but wait ... page is the link-type, NOT the table-name. Of course we could simply trick here and replace it hard-coded, but it's weird that not even TYPO3-Core has some kind of generic Class which will resolve this.

Any other utility-classes like LinkService, TypoLinkCodedService, TypolinkSoftReferenceParser and many more I discovered for a real "resolver" won't work or also require a table-name.

TypolinkSoftReferenceParser::getTypoLinkParts method comes very clearly to what I've been searching, but even there table-name is required and there's nowhere a mapping between table-name to link/record identifier like 'page' is table 'pages'.

I think this should't be hard-coded and always up to developers tricking around with such things and even TYPO3 core seems to poke around this basic problem, instead of providing a LinkHandlerMapper or some type of class we can use to manage/register linkhandlers to/from record table-name or link-identifier to the opposite.

The dirty mapping-logic done in TypolinkSoftReferenceParser::getTypoLinkParts should be refactored to it's own class and in such a way that we don't have to clue what table-name a t3link is ment for. Why is there the link-type 'page' if nowhere we use this to map it to pages table?

There are many core-classes which aim to provide anything for link-handling and we have link-handling configuration.

And additionally if we have t3links in our TYPO3-World it would be awesome to have a simple BE/Core ViewHelper which allows to render a record-link with icon just like be:uri.editRecord, but with argument for t3link, say it could be named be:typolink.editRecord.

It there's anything I didn't find please let me know. If my current view is really the fact, we should clean-up and refactor some things to make the linkhandler-feature better and better useable for developers for such a case I now had.

Actions
Copy link
 #1

Updated by Gabriel Kaufmann / Typoworx NewMedia 7 months ago ยท Edited

Just as a proposal and basis for discussion. If we don't want to touch too much, we could also extend LinkHandlingInterface.

currently linkHandlingInterface only is able to convert link-array to uri or a given record to link-handler array. Currently every LinkHandler-Array has it's own structure.

I think it would make sense to add:
  • LinkHandlingInterface::getSchema() : string returns baseUrn-Schema
  • LinkHandlingInterface::getUriSchema() : string returns baseUrn-Schema plus data-schema (see below)
  • LinkHandlingInterface::canHandleUri(string $urn) : bool to check if a given t3link uri is able to be handled by it
  • LinkHandlingInterface::canHandleData(array $data) : bool to check if a given link-array-structure is able to be handled by it
  • LinkHandlingInterface::getTableName() : string returns record table-name
  • LinkHandlingInterface::asArray(string $urn) : array to parse t3link into uri-parts

additionally I would vote for it to make the baseUrn-Property mandatory (or at least mandatory by interface method getSchema(), whereas the baseUrn should also contain placeholder-hints for the names used in data-array, for example as follows with data-schema.

URI including Data-Schema:
PageHandler: t3://page<&type:pagetype><&parameters:parameters><#fragment:fragment>
FileHandler: t3://file<#fragment:fragment>

Here we also see that all t3links have kind of common structure:
  • uid (mandatory)
  • type (mandatory)
  • identifier (optional)
  • parameters (optional)
  • fragment (optional)

If this would be converted to an Object we even could add methods to add custom-data (that may not be defined yet). I hate such arrays used everywhere even more if the data-structure is the same, but indeed isn't named in the same manner.

Actions
Copy link

Also available in: Atom PDF