[TYPO3-dev] ext_typoscript_setup.txt

[Elmar Hinz]

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

There is nothing else in TER. Indeed there CAN be nothing else in TER as
long as it needs a core hack to use it with the "oldstylish" extensions.

"Else" is on some of our 3.8 installations, where we hacked the core to
enable it. I can't estimate how many users work with a modified
css_styled_content or own developments. I think in general it a limitation
to be bound to those 2, that is not in the spirit of TYPO3 full
configurability.

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

As we already concluded even without explicit documentation it can
practically be regarded as a 4.x API with the same right and probability as
the addPItoST43. I don't expect that the usage of addPItoST43 will bring a
mesurable advantage considering migration to 5.x.

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

This day happens with migration from 4.x to 5.x. I don't expect that the
"same old" API is of much help then in the mayority of cases. If available
at all. I would not bet that 4.x extensions will run in 5.x without mayor
adaptions. More probably a "migration path" will be published, how you
bring your extensions from 4.x to 5.x. The addPItoST43 question, will be a
mosquito in comparism of probable alterations of the underlying data modles.

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

5.x must be build with all those modern patterns. Else I see no chance to
survive amidst all those modern PHP5 frameworks popping up.

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

Right. It is "polluting" whole page trees, where you never plan to use that
extension. I find myself

cutting off>

the configuration manually then, to get a better overview of the TS Tree,
maybe even to speed up the rendering a little.

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

I think an alteration of caching etc. could be to radical for 4.x and but
interesting for 5.x.

How about a switch during extension installation like Erik Svendsen suggests:

Chooe between

a) forced default setup
b) manual selection

for the 2 kinds of static templates.

Default would be a) for beginners. Experienced users switch to b) and
include static templates on tree level where really needed.

Regards

Elmar