Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible improvement of the default requestGetAttributeMapping for "site" #112

Open
ervaude opened this issue Feb 13, 2023 · 3 comments
Open
Assignees

Comments

@ervaude
Copy link

ervaude commented Feb 13, 2023

Hi,
I just noticed, that $request->getAttribute('site') is by default configured to return a Site object. The attribute could, however, also hold an instance of NullSite, so I reconfigured the requestGetAttributeMapping for site in our projects to the SiteInterface.

parameters:
    typo3:
        requestGetAttributeMapping:
            site: TYPO3\CMS\Core\Site\Entity\SiteInterface

Maybe you want to adjust the default configuration? Note, that this would likely lead to some new error reports for people, so if you don't want to do it, just close this issue :)

Thanks for this great package, we use it a lot.

Cheers

@sascha-egerer
Copy link
Owner

You're right. I'm a bit scared to change it as we then have again a change that required a large set of code to be "guarded" in many projects.
It would be pretty cool to be able to limit this to phpstan setups that your running with a high level but not for setups with low levels.
I've created an issue in PHPStan to ask about such a "level based config file load support". phpstan/phpstan#8887

@alexanderschnitzler
Copy link
Contributor

The attribute could, however, also hold an instance of NullSite, so I reconfigured the requestGetAttributeMapping for site in our projects to the SiteInterface.

That's technically right but it shows how bad this new kind of API actually is. What I usually want from the site, is the router. And that's only accessible through the implementation, not the interface. Even worse: Router needs a Site as constructor argument, not a SiteInterface. So, where do you reliably get a Site from? Not just during runtime, but also during static code analysis?

I think the core needs to streamline things and this issue is just a symptom of a pain that isn't caused by phpstan.

Another example is the routing attribute. Early in the middleware stack it holds an instance of SiteRouteResult, later in the stack it's overridden with an instance of PageArguments. Just horrible. And this is not a rant. I just saw this issue and was working on the aspects, another (still new enough) api which is annoying. ^^

@sabbelasichon
Copy link
Collaborator

@sascha-egerer I would not change it now. Only with a new release. Everyone can configure it nonetheless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants