State of PSR in Flow

Creating Neos & Flow Code
1

Before I continue with another post I wanted to create this as a reference point for the future, mostly for team members and to keep track of things:

PSR-0 “Basic Coding Standard” (deprecated) :white_check_mark:

This autoloading standard was removed from PSR but still works with Flow. It was the original Flow autoloading standard even before PSR-0 existed AFAIK. We rely on a few parts of it still and should remove those (autoloading in tests eg.)

PSR-1 “Basic Coding Standard” :white_check_mark:

Coding standard, fully integrated into our CGL.

PSR-2 “Coding Style Guide” :white_check_mark:

Coding styles, fully integrated into our CGL.

`PSR-3 “Logger Interface” :white_check_mark:

Logging standards. Since Flow 5.0 the log package can be used as PSR-3 logger and Flow can be configured to use any PSR-3 logger.

PSR-4 “Autoloading Standard” :white_check_mark:

Todays autoloading standard. Fully supported by Flow.

PSR-6 “Caching Interface” :ballot_box_with_check:

Caching interface. Our caching package offers implementations for the interfaces but there is not default way to use them in Flow applications and currently Flow/Neos do not use them at all.
Next steps:

  • Add a cache manager for these caches and a way to configure them (PSR-16 as well)
  • start using in Flow/Neos (packages)

PSR-7 “HTTP Message Interface” :ballot_box_with_check:

HTTP interfaces, my personal biggest gripe right now. Our HTTP request/response implementations also implement the PSR-7 interfaces, BUT we still need to shift our paradigm to replacing objects, using only the PSR-7 interface methods in Flow and deprecating the old HTTP methods.
Next steps:

  • Deprecate non interface methods and provide appropriate helpers where needed
  • Replace request/response objects consequently
  • adjust type hints to interfaces
  • Remove deprecated methods in next major

PSR-11 “Container Interface” :ballot_box_with_check:

Container interface, our ObjectManager fully implements the interface, but we could/should use that interface more throughout Flow and Neos.

  • Start using as type hint

PSR-13 “Hypermedia Links” :x:

Not implemented at all.

PSR-15 “HTTP Handlers” :x:

Not implemented at all. Needs PSR-7 fully done before IMHO.

PSR-16 “Simple Cache” :ballot_box_with_check:

Same as with PSR-6.

PSR-17 “HTTP Factories” :x:

Not implemented at all. Needs PSR-7 fully done before IMHO.

Bonus:

PSR-8 :white_check_mark:

Teams are definitely implementing HuggableInterface :slight_smile:

1 Like
2

Thanks for that write up! For me, the HTTP PSR-7 is the most important one that we should strive to fully support. There’s a lot of potential benefit, also regarding features that could be dropped in through 3rd party. Much more than with any other PSR, especially once PSR-15 is applied.

3

I find PSR-15 super interesting in terms of seperating the security package (move to middleware) from Flow to build a lighter version :slight_smile:

4

Yep, PSR-15 will allow us to do a couple of things more elegantly than they are now. Only thing I see is the controversial decision they made regarding the single pass approach and that this decision (though it’s fundamentally perfectly valid) makes it harder for us regarding our ComponentContext solution to still work in a meaningful way, because we no longer can create the Response object before invoking the component chain (which is our poor mans PSR-15 solution right now).

5

Nice one, thanks for starting this!
What about PSR-12 “Extended Coding Style Guide” (currently under review)?

PS: I took the freedom to link and title the PSRs in your original post

2 Likes
6

Didn’t take any unfinished PSRs into account but indeed we should probably look at it.

1 Like
7

Talked with Christian Kuhn at the TYPO3 camp Hamburg and it is really awesome what you can make when you have this middleware handling. It is part of TYPO3 version 9.3 I guess and you can adjust the bootstrap really easy. Would be awesome to have this. But will be also lot of work I guess.

8

In my opinion PSR-7 is one of the most important standards. If you follow this standard you are able to combine systems easily.

So if you have a system A that follows PSR-7 and PSR-15 you can write a middleware in system A that integrates stuff from System B (our flow) that also uses PSR-7 HTTP Requests.

So in a project I work on I could use the FLOW3 Application (when it is updated) as Authentication Middleware for a TYPO3. That would be awesome.