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

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 02.08.2006 16:58:

> We already have this plugin tree as:
> 
> "plugin.tx_mypinboard_pi1."
> 
> But in the tt_content list field the key for it is:
> 
> "my_pinboard_pi1"
> 
> That is the reason why we need to do a connection by hand (or by function
> that builds both ends) for each plugin in position:
> 
> "tt_content.default.list.20.my_pinboard_pi1."
> 
> An automated connection could be build by any renderer, if we would rename
> the plugin tree a little so that the key matches the database entry:
> 
> FROM: plugin.tx_mypinboard_pi1
> TO:   plugin.my_pinboard_pi1
> 
> Then the path "tt_content.default.list.20." could become flexible.

Yes, that would solve the most common type of FE-plugin. But this would
lead to some backwards compatibility problems, as many extensions have
the "plugin.tx_..." setup hardcoded in its setup.txt.

> The successor of addPItoST43() would just drop plugins in
> "plugin.my_pinboard_pi1". Any renderer could pick them up and use them in
> the way it likes.

The problem with it is that we have several different types of FE-plugins:

e.g. addPItoST43 allows us to be a "regular" frontend plugin
(tt_content.list.20.*), a "menu type" plugin (tt_content.menu.20.*), a
new CType (in which case some more complex TypoScript is needed). And
the kickstarter allows even more stuff: a typotag processor
tt_content.text.20.parseFunc.tags.$tagname$, a record renderer
tt_content.shortcut.20.0.conf.$tablename$, etc. I have summed that up in
some other mail in this thread.

So it is not enough to have a list of USER/USER_INT cObjects somewhere,
but we need some more complex TS-tree where all those cases are possible.

lib.registry.plugin.my_pinboard_pi1 =< plugin.tx_mypinboard_pi1
lib.registry.menu.my_pinboard_pi1 =< plugin.tx_mypinboard_pi1
lib.registry.CType.my_pinboard_pi1.10 =< lib.stdheader
lib.registry.CType.my_pinboard_pi1.20 =< plugin.tx_mypinboard_pi1
... etc

Maybe it is then even possible to skip the requirement of adding this
plugin TS "after" the content renderer, because the lib.* tree is
preserved in the TS from the content renderer (it only clears
tt_content.* before starting). If this would indeed be possible, then in
future the use of the replacement to addPItoST43 would not be so
important for those cases where a registry in lib.* is available.

Cheers,
Ernesto