[Typo3-dev] End of conflicting class extension/begin of APIs in TYPO3.6.0

[Kasper Skårhøj]

Hi FOlks.

I'm not here to start a thread about this topic again. I will not 
respond to it.

But I'm writing to you because there is one way of handling at least 
some of these problems which can be done without much fuss and right away.

This post will
1) explain how and
2) ask all of you who has developed extensions that had to extend a 
function but could have done processing by my suggested
method to send me a suggestion (within the next week). Then I can easily 
include it for 3.6.0RC2.

Finally; I hope that 3.6.0 can be released 4 weeks from now. A week 
before we will see 3.6.0RC2 out.



This is how it works;

CASE: Extension "realurl".
I'm working with Martin on the realurl extension to make it use this new 
kind of API instead of having to extend the "tslib_fe" class - as you 
know that is a "dead end" for extensions and something that primarily is 
a last-resort since it doesn't scale. Thats an old discussion.
But what can Martin do then? He needs to for instance manipulate EACH 
and EVERY link that TYPO3 makes for a website. So that "index.php?id=12" 
is rendered "http://..../My-page-title/" etc.

Well, Martin made an extension of the simulateStaticDocument function. 
It turns out that a better function to extend would be 
t3lib_tstemplate::linkData since that function generates ALL links for 
the frontend.
Inside of this function I have now added an "API" of a few "standard" lines:





			// Call post processing function for link rendering:
		if 
(is_array($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['linkData-PostProc'])) 
{
			$_params = array('LD' => &$LD, 'args' => 
array($page,$oTarget,$no_cache,$script,$overrideArray,$addParams,$typeOverride));
		 
foreach($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['linkData-PostProc'] 
as $_funcRef)	{
				t3lib_div::callUserFunction($_funcRef,$_params,$this);
			}
		}

			// Return the LD-array	
		return $LD;




What it does is RIGHT BEFORE the product of the linkData function, $LD, 
is returned it looks if some php function/class has been configured for 
doing post processing of the output. And if so it will traverse all 
configured pass-through functions, call each of them with the $LD 
parameter as a reference in the params array and that means any 
extension can configure a function for doing post-processing on this. 
This is enough for Martin to do his "realurl" tricks - and he doesn't 
take up a "class-extension" space...




This kind of API doesn't cost more than a check of a global variable, it 
is 5 simple lines and can be added quite easily. So I will now suggest 
all extension developers having to extend classes; please consider if 
this kidn of API inserted somewhere in TYPO3 could be used by your 
extension so that class extension can be avoided. If so, please suggest 
that to me ASAP.

- kasper