[TYPO3-dev] ext_typoscript_setup.txt

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 25.07.2006 18:33:

>> Hm, I am not sure what you mean with "core hack"? I don't think anything
>> has changed, and still everything works "as usual" (meaning all
>> extensions are still working as they were in previous versions).

> I try to relocate the "core hack". If everything works like usual this
> means IMHO that you can't replace css_styled_content with another rendering
> setup like you imagine, because it would have the wrong id. All extensions
> work.  But they only work with css_styled_content or "content (default)",
> but with nothing else.

There is "nothing else", as far as I know. :) And "43" is just in the
name of the method, is not mentioned anywhere else in the source code.
This was just a short for of referring to "content (default)".

>> tt_content.list.20.articles_edit       =< plugin.tx_articles_edit
> [...]
>> It works fine because of the hardcoded reference to a place in TS where
>> the content rendering expects it to be. But I think this is neither
>> documented or bound to be supported forever (but probably will for
>> "backwards compatibility reasons").

> You have yourself defined it as the api 2 postings before :-)
> 
> This "inteface" include defining and using the following
> TS branches:

This has to be documented and as this is not the case currently, I
wouldn't trust using this interface. And anyway, this isn't an interface
I would like extensions to use.

> includeLibs.*
> plugin.*
> tt_content.list.20.*
> tt_content.menu.20.*
> tt_content.splash.*
> lib.stdheader.10.*

This is the TS-glue that connects the FE-plugins with the content
rendering engines. This is the interface content renderers work with
(because both addPItoST43 *and* content renderes are in the CORE), but I
wouldn't say this is the interface FE-plugins should work with.

>> So your idea would be to use those defined places in the TS-tree to put
>> in your information? If this is the interface to use (a naming
>> convention instead of a PHP interface), we must document and make sure
>> all content renderers adhere to this conventions.

> But you are right. Best if only one of them would be defined as THE api.
> Either a PHP function or this TS tree.> 
> I bet you agree that it is unlikely that this tree will be altered within
> the 4.x Branch.

True, I think it hasn't changed since the beginning. But we shouldn't
make it more difficult to change it in future.

Maybe someday the content rendering doesn't go through TypoScript at all
(maybe just through some Smarty stuff or whatever?). Even in this case,
the "same old" API call to register it would work. Which is why I prefer
having a PHP method to do it, as it is more future-proof.

> It could change and probably will change with 5.x. With 5.x so much will
> change, that it is difficult to plan for it yet. I am sure that there also
> will be no function with the name addPItoST43.

Yes, I hope so. While refactoring in 5.0, this is a place where I would
use a factory and registry: extensions register FE-plugins (call to
"addPItoST43-successor"), and content rendering engines loads and run
those plugins using a factory and the plugin's "key".


Another thing about this topic (some kind of "vision" I just had):

The main problem Elmar seemed to have with these methods is that they
provide some TS-snippet that is applied to your whole site. Maybe we
just need a way to be able to load ext_tables.php and ext_localconf.php
from an extension template so that they can be loaded on demand. So one
could have:

static/setup.txt
static/constants.txt
static/ext_localconf.php

In the last file you could call addPItoST43 and other addTypoScript
methods, which will then just be reflected in the current page tree.
There are probably tons of issues involved (like having to cache
multiple versions of the "combined" ext_localconf.php), but it might be
solveable.

Thoughts?

Cheers,
Ernesto