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

[Elmar Hinz]

Hi Ernesto,

Ernesto Baschny [cron IT] wrote:
> 
> 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).
> 

Playing with alternative content renderes makes a lot of sense within 4.x:

A) to get better rendering
B) to get a more simple configuration (HCI)
C) to have time to find the best tree for 5.x before everything must
   be decided
D) to enable agencies to work with customized versions of
   css_accessible_contents
E) to do creative experiments with TYPO3

Currently is is not easily possible to do any of this, because
addPItoST43() blocks it.

Both of your proposals would be possible, a function or a
"lib.plugin.tx_xyz" tree. Using a function would be backward compatible
with the old addPItoST43() so that a lot of plugins could be used within
the new renders without alteration.  A "lib.plugin.tx_xyz" tree could be a
future move.

I propose 3 steps:

1.) Fixing addPItoST43() so that other renderes can be used with it.
2.) Providing an alternative function with a better name, where a plugin
    entry point can be registered by the renderer like you proposed.
3.) Matching old addPItoST43() to the new function so that old plugins work
    within other renderers.


>> 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).

That is the old story of the hen and the egg. Currently no other content
renderer can appear, because it would be blocked. I have shown a way how to
get the first egg. A global variable is not a hack within 4.x but an
established standard. 4.x works with a bunch of global variables and also
has a naming system for them.

Regards

Elmar