[TYPO3-dev] ext_typoscript_setup.txt

[Ernesto Baschny [cron IT]]

Elmar Hinz schrieb am 25.07.2006 15:03:
> Stefan Geith wrote:
>> This could be made by ext_typoscript_setup.txt ;)
>> 
>> Some kind of configuration, that leads to a
>> warning message from the plugin.
>> The definition of a special constant could disable
>> this message/configuration.
>> (...)

> the ext_typoscript_setup.txt question is probably not so clear to answer as
> the 43 problem. tt_news doesn't use it. I am often neved by settings in the
> TS Tree that I never requested.

I think Stefan suggests to use ext_typoscript_setup.txt just for
displaying a warning that no valid TS template has been included. This
will generate a "default" error output for your plugin instead of not
outputing anything at all. Remember people upgrading from tt_news v.OLD
to v2.x and no output was being generated because no static template was
included? A warning would have given the hint.

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.

This would require some kind of default setup for each plugin that is
installed, which is what ext_typoscript_*.txt already does. So I'm not
totally against it, but it has to be strictly specified what exactly is
meant to go into ext_typoscript_*.txt and documented how custom
configurations can be loaded by experienced users "on demand".

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

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
T3-extensions. This "inteface" include defining and using the following
TS branches:

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

I find it cool that addPItoST43 takes care of these setup without the
user having to find out where to place their code in the TS-tree so that
the content renderer will be able to render it. In a refactoring maybe
we just need to rename and split the method so that it is clearer what
the plugin is adding:

t3lib_extMgm::addFrontendPlugin(...)
t3lib_extMgm::addFrontendPluginAsMenuType(...)
t3lib_extMgm::addFrontendPluginAsContentType(...)
....

So my suggestion:

- keep t3lib_extMgm::addTypoScript (and its shortcut interface
addPItoST43) for TS code that is strictly required to get the extension
working as a FE-plugin in the first place. Maybe split/rename addPItoST43.

- keep ext_typoscript_*.txt files provide a default configuration for
"plug-and-play" experience. Document what is meant by this.

- someday add an option for the admin to "disable" ext_typoscript_*.txt
settings

- static/* to be loaded on demand where the admin wants to in the page tree.

Elmar also wrote:

> 1.) Look into the leading extension tt_news. I think it shows the modern
> way how to include TS.

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


Cheers,
Ernesto