[TYPO3-mvc] RFC: Handling of Settings and Extbase configuration
Sebastian Kurfürst
sebastian at typo3.org
Mon Aug 3 11:18:42 CEST 2009
Hi,
this is an RFC.
Problem:
Currently, there are two different settings:
- Domain specific settings: residing in plugin.EXTENSIONKEY
This is everything you have available in $this->settings in the
controller, or in {settings} inside your template. This might
include ViewHelper configuration, email addresses, the number of
posts to display, ... (In short: everything you need inside your
controllers or views)
- Framework Configuration: residing in tt_content.list.20.PLUGINKEY
You can fetch this configuration through
Tx_Extbase_Dispatcher::getSettings(), though, _you should not_
fetch it! We will mark this method as internal, and if you call
it, it is on your own risk.
Framework configuration contains:
- should the cache be cleared automatically?
- where to fetch records from
- where to store new records
- (later maybe): Dependency Configuration settings
We do not like that these two places for configuration exist and are
very in-transparent to the user (the instanciator of the Extension
potentially needs to change both places!). However, placing them in a
shared namespace would not be good either, as this mixes up domain
specific settings (which we can forward-port) and framework specific
settings (where there is no such equivalent in FLOW3).
Proposed Solution:
1) Rename Tx_Extbase_Dispatcher::getSettings() to
Tx_Extbase_Dispatcher::getFrameworkConfiguration()
I'd like to clearly disambigurate these two terms: "Extension settings"
and "Framework configuration", and thus I'd like to rename the above method.
2) Add a big doc comment to
Tx_Extbase_Dispatcher::getFrameworkConfiguration stating that you should
not call this method.
3) Restructure settings the following way:
plugin.tx_EXTENSIONKEY {
settings {
// This will be domain specific settings available in
// $this->settings and {settings}
}
classes
enableAutomaticCacheClearing
storagePid
}
Inside the automatically generated TypoScript when registering the
plugin, we will now add the following lines:
tt_content.list.20.PLUGINKEY.enableAutomaticCacheClearing =<
plugin.tx_EXTENSIONKEY.enableAutomaticCacheClearing
tt_content.list.20.PLUGINKEY.storagePid =<
plugin.tx_EXTENSIONKEY.storagePid
tt_content.list.20.PLUGINKEY.classes =<
plugin.tx_EXTENSIONKEY.classes
This has some benefits:
- The normal end-user finds all potentially interesting configuration at
one place
- He cannot destroy anything, by f.e. accidently setting his plugin to
"USER_INT" instead of "USER"
- The Framework Configuration is not polluted with domain-specific settings.
What do you think about the above ideas?
Comments are warmly welcome :-)
Greets,
Sebastian
More information about the TYPO3-project-typo3v4mvc
mailing list