[TYPO3-dev] Protection of a bug WAS: ext_typoscript_setup.txt

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 02.08.2006 10:03:

>> Elmars bug report http://bugs.typo3.org/view.php?id=3930 would handle
>> that in a "global way", but as I already commented, I would support a
>> better design pattern in 5.0 for this interaction between FE-plugins and
>> content renderers.

> do I understand you clearly?

I think not, because I think you haven't noticed that my assessment of
addPItoST43 changed because I wasn't aware of all technical details
behind it. With your help and hint I noticed that it needs to add the
created setup after the "content rendering" static template, which is
found by its id=43 or by the special case csc. This of course is very ugly.

This is why my "to sum up" opinion was that a better design pattern is
needed for the integration of FE-plugins in content renderers.

addPItoST43 currently takes care of two things, which we need to replace
with something better ((a) is the one I wasn't considering):

a) some way to register certain TS to be placed *after* any content
renderer. One way would be to make sure the content renderers TS is
always placed on "top" of the tree, the other would be to mark the
content renderers TS somehow so that TYPO3 can know where to add the
FE-plugin TS.

b) some documented TS where the plugin "hooks" into the content
rendering setup. I would not be a fan of those hardcoded paths to
TS-objects as we currently have. We might move all this to lib.*, which
is also being used for example for parseFunc_RTE (content renderers just
reference to that).

> On the one hand you recommend that the function addPItoST43() as the only
> valid API to rendering setups?
> 
> On the other hand you recommend not to fix deficient behaviour to do
> exactly this, to give access for different rendering setups? You recomment
> this until 5.x when this function will fall away anyway.

My reasoning is that there is no need to fix something with some "hack"
(a global variable) that noone will use anyway (as I don't expect any
other content renderer that is not based on c(d) and csc to appear
before 5.0).

Cheers,
Ernesto