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

[Martin Poelstra]

Hi Kasper, List,

> 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.

True, but how can I now translate the URLs back to ID's? There has to be
another entrypoint, like I created with checkAlternativeIdMethods() and
fetch_the_id(), both of which are needed in the current approach.
Furthermore, everyone has to upgrade to Typo 3.6.0 to be able to use
RealURLs. This might not be a problem if it's just about one extension,
but many will follow, during the use of 3.6.0 too.

> Inside of this function I have now added an "API" of a few "standard"
> lines:

Sounds good.

> 			// Call post processing function for link rendering:
> 		if
> (is_array($TYPO3_CONF_VARS[...][...][...]))

Maybe replace is_array(...) with (count(...)>0)? This way it can be
initialised as an array.

> 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...

You say, 'any extension can configure a function for doing
post-processing', do you mean that extensions will now be able to create
the /forum/thread123/post456-thing? Because I think more is needed for
that to work, so in that case the API should be extended a little more.
Furthermore, if many extensions are going to hook functions up this way,
how does one control the order in which they are 'stacked'? Maybe by
giving some 'preferred index' (0-100)?

> 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.

It's a good thing if this kind of API's are created in my opinion.
However, the disadvantage is that if someone wants to use an extension for
which an API-hook had to created recently, you have to keep upgrading
Typo.

Though I'm very proud that my extension is used as a case here, I think it
might be better to think somewhat longer about the RealURL API, create a
test-API, test it with e.g. the news-extension, forum, etc. and when it's
working include it in 3.6.1, because to me it seems that just creating
some sort of API in a very short time, without giving people the time to
test it on their extensions isn't such a good idea (they will have to
update their code if they want to use the RealURL-things like
/forum/threads123/post456...).

Until then, we can just use the approach I sent to Christian this
afternoon, that uses an intermediate extension url_api, that can later be
integrated in the Typo3 core, like cms.
If someone's interested, I'll repost that idea to the list.

Conclusion:
API's in the TypoCore: Good!
RealURLs API: Good! But not for RC1, that's just too soon. Not for me, but
for the functionality that's needed by the other extensions. (Unless we
think of something really good in this week or so...)

Thnx,
Martin

P.S. Sorry about the lengthy mail ;)