[TYPO3-dev] ext_typoscript_setup.txt

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 25.07.2006 17:04:

>> The problem here is also usability and the way newbies feel when using
>> TYPO3. They want to install an extension and see it working
>> ("plug-and-play") without further fiddling and I can understand the
>> frustation when it doesn't.

> If it is handled in a unique way, even the newby will understand the
> principle quickly. As everynewby installs tt_news everynewby will learn it
> anyway. :-)

True in some way, but still frustrating for the first time user. I don't
think one should need to read much documentation to set up a small site
with news on it.

>> Maybe the best would be an option for an experienced admin to deactivate
>> ext_typoscript_*.txt files altogether and work just with static templates.

> Well, that goes to the core team.  :-)

Right, and if I don't forget this, I try to bring those stuff up in the
T3DD.

>> Regarding addPItoST43 I would say that just the name is misleading. Its
>> functionality has nothing to do with a template "43". Every content
>> rendering extension should just provide the same interface as content
>> (default) (the "original" template 43). css_styled_content has always
>> been doing that already. Doing that, it will be able to render all
> 
> In 3.8 a core hack was necessary to assign another template into the
> functionality of original 43. There was a special core hack in it for
> css_styled_content. Has this changed with 4.0? I didn't hear anything of that.

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

The hook in the "content (default)" (which happen to have ID 43) are
also being used in css_styled_content. If another content renderer has
another idea of how the plugins should register themselves, its just a
matter of XCLASSing t3lib_extMgm::addPItoST43 and direct the requests
from plugins to other places in the TS-tree.

> As long as you would need to hack the core to make your rendering extension
> work with addPItoST43, the tt_news way to add templates is the solution.

Wrong, the tt_news way is the only "hack" I see here. All extensions
running through addPItoST43 are the "way to go" in my opinion (except
for the name of the method), because this is the interface that links
FE-PLUGINS with CONTENT RENDERING. This has to go through the core
(using the TS-glue), because else this will be a chaos if it isn't
documented, as you won't have any chance to change that in future.

> And if that will ever fixed in there should by an alternative name
> available for the function. Anyway using a TS template to set TS looks more
> transperent and intuitive to me than using a PHP-Function to generate TS.

The problem is that you need to "register" your plugin into the content
rendering engine. There are several places you might want to do that
(register as a regular plugin, as a header title, as a menu-type, see
kickstarter for a list of possibilities). All those registration
currently run through addPItoST43.

You propose that we define (and probably document) a fixed set of
TypoScript places. I think this goes against your idea of a "hardcoding"
stuff into the core. What I propose is to use a clear interface which
content renderers AND FE-plugins follow, and this what addPItoST43
already is (just with a bad naming).

>> The "tt_news" example is really a bad example here, because it's support
>> has always been included in the in core (hardcoded). Which is why it
>> doesn't need to call addTypoScript or addPItoST43. Then every content
>> rendering needs to make special setup (like content (default) and also
>> css_styled_content) just to make tt_news also gets called. I don't think
>> this is the solution. :)

> I think your argumentation is to complicated here. My extensions are not
> specially supported by the core and they work fine with this technic.

If I take a look at "article", you have hardcoded the interface to the
content rendering in your TypoScript:

tt_content.list.20.articles_edit       =< plugin.tx_articles_edit

You think this is good style? :) This would have been done by
addPItoST43 without you having to know where the content renderer
expects it to be. Maybe in future some content rendering developer want
to have these in "tt_content.10.list.20.*"? Your extension won't work
anymore, mine would. :)

> Just like Stefan has describied it earlier in the thread.
> All I need is one
> 
> t3lib_extMgm::addStaticFile($_EXTKEY,"pi1/static/","Some Label");
> 
> in ext_tables.php. The rest is in the TS template in the usual TS way,
> transparent and under full controll of the TS developer.

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

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.

Cheers,
Ernesto