[TYPO3-dam] DAM, RTE, <media> and ts_links

[René Fritz]

I would like to discuss the RTE linking solution included in 1.1beta05.

This seems to be one of the most wanted features, so I would like to get some 
feedback if it's working as expected.

For detailed information have a look in the manual of the dam extension, 
section "RTE and <media> tag".


What is it all about?

The RTE just generates <a> tags with a reference to a linked file. To make use 
of DAM features, this tag needs to be converted when saving the content to 
the database. (Such things are configured with 
TSconfig 'RTE.default.proc...')
In FE that special tag needs to be rendered as an <a> tag like TYPO3 does with 
<link> tags.


<media> vs <link>

First some background information:
I thought a good solution would be to use the known <link> tag which would 
look like that for a link to a dam asset:
<link dam:243>Link text</link>

The main disadvantage would have been that the RTE processing rule "ts_links" 
needs to be overridden with an own version. ts_links is called when the 
shortcut ts_css is used for example:
RTE.default.proc.overruleMode = ts_css

So I decided to use a new tag <media>. For FE rendering an own .tags.media 
parseFunc can be registered and for RTE processing the system rule ts_links 
does not need to be overridden.

The problem is that the RTE generates <a> tags and however both ts_links and 
the <media> processing does not work at the same time. In the end I had to 
override ts_links (what I wanted to avoid) to make <a> to <media> tag 
processing work.

The conclusion is, in principle the format <link dam:243> could be implemented 
because I override ts_links anyway. But I think the new <media> tag might be 
more flexible in the future.


<media> parameters

The media tag use the same parameters as the link tag. The question is, is 
that a good decision, or should another scheme be used for the media tag? The 
disadvantage of the link tag is that parameters have to be in the right 
order. A naming scheme for the paramters might be more flexible.


What do you think

René

-- 
COLORCUBE
digital media lab

www.colorcube.de