[TYPO3-dev] The extbase dilemma

[Björn Steinbrink]

Hi,

On 2011.05.26 12:20:09 +0200, Bastian Waidelich wrote:
> Daniel Brün wrote:
> >We applied a (dirty) fix to accelerate this process by caching
> >links (sounds simple, but is not in fluid).
> 
> Actually it's just a couple of lines of code if you use Dependency
> Injection as described in the wiki [1]:
> 
> in Classes/MVC/Web/Routing/UriBuilder.php:
> 
> <?php
> class Tx_MyExtension_MVC_Web_Routing_UriBuilder extends
> Tx_Extbase_MVC_Web_Routing_UriBuilder {
> 
> 	protected $firstLevelCache = array();
> 
> 	public function uriFor($actionName = NULL, $controllerArguments =
> array(), $controllerName = NULL, $extensionName = NULL, $pluginName
> = NULL) {
> 		$cacheHash = 'foo'; // create unique hash based on given settings
> & parameters
> 		if (!isset($this->firstLevelCache[$cacheHash])) {
> 			$this->firstLevelCache[$cacheHash] = parent::uriFor($actionName,
> $controllerArguments, $controllerName, $extensionName, $pluginName);
> 		}
> 		return $this->firstLevelCache[$cacheHash];
> 	}
> }
> ?>
> 
> 
> In ext_typoscript_setup.txt:
> 
> config.tx_extbase.objects {
> 	Tx_Extbase_MVC_Web_Routing_UriBuilder {
> 		className = Tx_MyExtension_MVC_Web_Routing_UriBuilder
> 	}
> }

Unfortunately, it's not that easy. Since you override the general URI
builder implementation there, you need a non-specialized solution[1].
And uriFor() is too early in the call chain, especially if one plans to
just wrap it. The final arguments aren't there yet, so the cache key
creation would need to duplicate code from lower levels. And since
typoLink() isn't purely functional (it accesses global variables), such
a cache key generator would need at least _some_ of the logic that's
buried in there to be generally usable.

Björn

[1] I just had a quick glance over the object container code, and in
fact, since the object container is a singleton and the registered
implementation classes aren't cleared (AFAICT), you'll easily get into
trouble anyway when you run first run plugin A that registers an
alternative implements for class X, and the run plugin B in the same
request, which is incompatible with that alternative implementation.
And I think similarly bad things happen, when you dispatch one extbase
plugin from within another (using e.g. the cObject view helper, or
whatever). The "inner" one might reconfigure the object container, so
the "outer" one suddenly sees different objects.

So independent from this use case, you'll probably want to get rid of
the singleton stuff there.

-- 
*Björn Steinbrink*
*fon*: +49 (0) 521 - 329647-21
*fax*: +49 (0) 521 - 329647-40
*e-mail*: steinbrink at saltation.de
http://www.saltation.de
---------------

saltation GmbH & Co. KG | Niederwall 43 | 33602 Bielefeld

Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344

Persönlich haftende Gesellschafterin:

saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld

Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339
Geschäftsführer: Daniel Brün