[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