[TYPO3-dev] stable = documented ?

[Ernesto Baschny [cron IT]]

steve ryan schrieb am 26.07.2006 05:49:

> Mechanisms for injecting configuration
> *($this->conf)
> 1 - constants and setup in sys_template records
> 2 - ext_typoscript_setup.txt and ext_typoscript_constants.txt
> 3 - static/pi1/setup.txt and static/pi1/constants.txt
> 4 - fields in tt_content related to specific plugin BAD
> 5 - flexforms
> 6 - template constant editor
> 7 - loading of arbitrary TS style config files (based on other config)
> 8 - php definitions in ext_localconf.php

Nice summary! Thanks Steve!

> Thoughts
> * it is desirable that a plugin works out of the box for beginners

Agreed.

> * seperation of cascading (TS) or per content (fields/flexforms)
> configuration

I would say this is needed but is currently a mess, as every extensions
does it differently.

> * where is configuration loaded/combined - extension rendering,
> extension loading

If we ban everything to includable static templates, it has to be only
at extension rendering. That also makes sense, since you don't want to
load the forum stuff in the whole site tree where you just use the forum
in one tiny branch.

For the sake of newbies and "plug-and-play" experience, Tapios idea with
a switch at extension creation would be nice (enable "global default
setup").

> * removing junk configuration for efficiency ??

Define "junk". :)

> * who is setting configuration - users, admin, developer

Usually an extension developer doesn't think much about that and just
creates his extension the way he will need it. This is why we have stuff
that can be overwritten through a flexform setting, others have
constants that can be edited in the constant editor, other constants
doesn't even appear in constant editor and others still are only
available in the TS-setup.

> * seperation of configuration - default(2),

Agreed, using Tapios idea ("enable feature").

> preset customisation(3/5/7),

Why 5? A flexform (I guess you mean pi_flexform field) is empty by default?

> arbitrary customisation(1/4/?5)

And there is also a category of "required configuration": the basic TS
to get the plugin rendered and maybe some constants that are required to
be filled in for something to be shown, like pids, etc. Usually one has
no idea what is really strictly required without having to go to the
extension documentation hoping that the developer has documented it well.

> * interpretation of empty/invalid configuration. User feedback at
> extension rendering.

Would be nice and not that difficult to have that. All it takes is
something like this in the content renderer (c(d) or csc):

tt_content.list.20.default = TEXT
tt_content.list.20.default.value = Plugin {field:list_type} cannot be found!
tt_content.list.20.default.insertData = 1

If the plugin is being called, then its up to the plugin to return
errors/warnings if something is missing in the configuration (like a
template file!).

> * known mechanisms/standards - _DEFAULT_CSS, static templates,
> sys_template records, table=, global storage page

Yes, I think some of those concepts need some serious "wrap-up". Here
there is also the personal-taste issue: I might not be using this or
other TYPO3 feature, but there might be tons of people that are. It's
difficult to clean up, while having to maintain so much code we don't like.

> * order of inclusion (order of extension installation/template inclusion)

For FE-plugins and using the proposition of having no "global" TS-setup,
the order of static template inclusion should be the only one that
matters, which is why you can already order those in the list in your
template.

Technically possible but I don't think we need the overhead: having some
kind of dependency-checks for loading-order, like we have in RPMs:

css_styled_content
- provides "content rendering"

tt_news css-styled
- requires "content rendering"
- provides "tt_news basic"

tt_news_rss
- requires "tt_news basic"

etc. This would enable auto-ordering of items, and also provide some
"basic" consistency checks (like loading csc and c(d) in the same
template, as both provide "content rendering").

The other order is for BE-modules and other things that extensions might
do (XCLASS, etc). Currently its pretty much the order of installation,
but there is no easy way to manipulate that. We could use the already
present "constraints" array from ext_emconf.php to generate a "correct"
order of loading and point to inconsistencies. But this might be not
enough, so maybe its just easier to have an interface in the BE where
you can alter the order the loading of extensions in a select box.

> For my money. I set pretty much everything configurable as defaults and
> examples and reference in ext_typoscript_setup.txt and
> ext_typoscript_constants.txt and use flexforms or template records to
> tweak. I have used flexforms for preset style configuration. I guess
> static templates also fill the preset role in a somewhat less intuitive
> but cascading manner.

Yes, the nice things about static templates is that their settings apply
to a whole "page tree". Its usually not clear that for most extensions
those defaults apply if there are no settings in flexform that overwrite
those. So it would be cool to be able to present the defaults (coming
from static templates) besides the fields in the flexform.

> I don't see the problem with dumping a whole stack of working/example
> config as a default. It's easy enough clean up - plugin.blah > or
> whatever else is an appropriate inclusion method.

Easy to clean it up, but you don't even need to pollute the "global
space" with extensions at the first place. It might be easy if you have
just one site and one "main template", but imagine some installation
where you have several sites and several templates controlling them.
Installing a single extension would mean adding TS setup that needs to
be parsed on each site, even if you just need it in a tiny place of one
site.

Cheers,
Ernesto