Slim 4.0 Road Map

[codeguy]

Here are some intiial thoughts:

• [BC break] Extract Slim\Http into separate PSR-7 component (ONLY PSR-7 methods)
• [BC break] Create custom decorator classes to hold Slim-specific additions to PSR-7
• Accommodate additional media type parsers in request
• Address issues reported by Phan
• Improve test coverage

Additional ideas:

• [BC break] Remove Request, Response and Env from container (@akrabat)
• [BC break] Don't set content-length by default. Provide a middleware for people to use if they want to. (@akrabat)
• Make it faster (or at least don't slow it down!) (@Cyrille37)
• [BC break] Removing Method-Override and providing a middleware (@geggleto)
• [BC break] Decide if we need subRequest at all (@codeguy/@silentworks/@geggleto)
• Lazy resolve route middlewares (Lazy resolve Route middleware #1635) We already do this with route callable(only resolve the matched one). (@mathmarques)
• Look at __invoke and run on App and see if we can consolidate functionality and make them easier to unit test. (@geggleto)
• [BC break] Consolidate error handlers for exceptions and PHP 7 errors (@akrabat)
• Can we avoid statics in Slim\Http? See (Thoughts?) Feature - Allow users to Specify their own Http Classes Easily #1850 (@Raistlfiren)
• [BC break] Look at pathFor()'s parameters? see More flexibility for URL parameters #1800 (@akrabat)
• [BC break] Do something about basePath from Request. Maybe middleware solution instead? (@akrabat)
• [BC break] Remove determineRouteBeforeDispatch and make routing a middleware that can be placed where you want it to be. If you don't add it yourself, we would add it immediately before dispatch. (@akrabat)
• Use getallheaders() to get the Authorisation header. (irc channel)
• Move documentation into main repo and publish to website on each new release. That way we can insist on documentation with the PR.
• [BC break] Either rename Slim\Exception\SlimException or remove it.

Please add additional thoughts below.

[jeremygiberson]

I'd like to see something like a ModelResponseInterface with the following definition:

interface ModelResponseInterface {
    /**
     * @return mixed
    */
    public function getModel();
}

Right now because the framework requires a Response to be returned from middleware it makes it difficult to do things like writing content-type middlewares that marshal models into json/xml/etc. Officially supporting a response type that provides a container to pass models/objects back to middlewares for processing would be really nice. This could be it's own package too. I just think there should be recommended package at least. That way we will hopefully start seeing HAL rendering middlewares and similar things pop up.

[Cyrille37]

Please, for the Slim roadmap, keep the velocity in priority one. It exists several really greats light frameworks like Lumen and Silex. In my mean Slim is the fastest and should keep the lead.
If one like Lumen or Silex is light and fast as Slim, it will be easier to use them because switching between larger (Laravel, Symfony) will be natural.
Cheers

[geggleto]

@codeguy @akrabat @silentworks ... we should look at Groups again.

[lalop]

With route in a separate middleware and http's classes in a separate repository it seems that Slim's core will not have anything to do with http.
It could be good to define the issue this library want to solve.
it will look like a middleware stack with a container.
On my point of view it could manage any kind of request with the appropriate trinity request/response/router ( http, cli, ... )

[danielgsims]

Remove the VERSION constant from App? It's fallen behind. See #1886

[mathmarques]

What about a setting to change the middleware stack(execution) order?
We use the "Last In First Executed" by default, but we could add a setting to change this behaviour to "First In First Executed" like others frameworks.

[llvdl]

Either document slim.files option for Route::createFromEnvironment and add tests or remove the Environment argument and rename the function to Route::createFromGlobals [BC break] (see #1899)

[marcelbonnet]

Hi, suggestion: allow us to set our own \Slim\Route impl . See #1906 . By now (3.4.2), it is possible, but at risk to break something (since we need to alter part of the Slim\Router::map function to point to our own Route impl)

[geggleto]

Better documentation of internals, notably describing the call-stack for an execution of a route action.