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

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 02.08.2006 14:02:

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

Ok, I think you are convincing me. :)

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

As in your bug report, right?

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

See my other post.

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

True.

Comments in the feature request: http://bugs.typo3.org/view.php?id=3930


Cheers,
Ernesto