Add autocompletion and type-hinting on TYPO3 context API

[ipf]

The TYPO3 code can be found here

Expected: Using a statement such as $languageAspect = GeneralUtility::makeInstance(TYPO3\CMS\Core\Context\Context::class)->getAspect('language'); should result in the proper type-hinting for $languageAspect and also provide autocompletion for the selected aspect.

This only works in TYPO3 9, see https://docs.typo3.org/typo3cms/extensions/core/latest/Changelog/9.4/Feature-85389-ContextAPIForConsistentDataHandling.html

[cedricziel]

@bmack could we alter the AspectInterface, so the name can be inferred statically?

Like:

public function getName() : string {
    return 'user';
}

Parsing the stuff in the context class constructor is guaranteed to break and I would like to provide completion for the context names.

I also think it might be better if the names are not inlined in the context class.

[bmack]

uuuh, I see @ipf working with the context API. I thought I was the only one understanding and using this.... NICE.

Main issue with that is that an aspect does not know its name (see useraspect - it's used twice). Because it is kind-a inject into a context, you could even use the same aspect twice in one context.

[bmack]

Can we do some kind of "getReflectedAspectsWithName" internal API thingy within T3 to use that as base "I'll tell you what I have, what types and what names are there?"

[cedricziel]

That API is super nice! - Thank you for solving the problem so we don't have to over and over again :)

Sneak preview - that's what's currently up with #242 :

The aspects are referred to by alias - such as frontend.user. To have some meaningful support in the IDE, I need to create a mapping between these aliases and their FQCNs. I can do this in a static map for the default aspects since I don't expect them to change that often.

But when another aspect is added via middleware (such as a principal for example), how do I detect those then? I cannot execute PHP Code. I always have to look at patterns, such as method calls. Unfortunately the IDE limits me to the AST.

Do you think it's feasible to rely on a pattern like "look at all setAspect calls in middlewares", or do you see another pattern, where we can make sure, we don't collect false-positives? Are there special places where aspects are added besides middlewares?

That's where a statically dumped container really shines, and dynamic dependencies fall really, really short. :/

[bmack]

Let's get olly in here, he and Susi basically set up the architecture, I'm not the master brain actually.

Btw / unrelated: The day when you get remove the $GLOBALS['TSFE'] analyzer, I will send you a beer with DHL! That day will come.

[cedricziel]

When that day comes - You'll get one as well! :)

[cedricziel]

Feature itself is implemented - re-opening for discussing further means.