Implement PSR-7 to replace HTTP Foundation throughout strategies about route

[philipobenito]

100% the plan once it's accepted 👍

[codeguy]

Sweet. Good news. Feel free to close this out.

[philipobenito]

Worth keeping open for clarification to others, I'll rename to reflect as a task

[philipobenito]

@codeguy would actually like your input re a middleware strategy if you'd be OK with me shooting you an email when I have a bit of time?

[codeguy]

Sounds great! You can reach me at hello at joshlockhart dot com.

[philipobenito]

Good man, thanks

[philipobenito]

Just another quick one, are you planning an implementation of PSR-7 for Slim 3? Obviously we'll be waiting a while for the Enterprises so if you are planning something, I'd give you a friendly nudge to make it a standalone package :-)

[codeguy]

Yes Slim 3 will have PSR-7 messages objects. I should probably split that into a separate component for sure.

[philipobenito]

Would be ideal for me, don't want to take the implementation on myself right now but obviously need to point to an implementation once I swap it out

[hannesvdvreken]

@philipobenito about middleware strategy: I think stackphp will depend on PSR-7 instead of http foundation once it's out. So imo following stackphp would be a good move.

Instead of depending on an implementation of PSR-7, league/route should depend on psr/http-message.

[philipobenito]

@hannesvdvreken PSR-7 === psr/http-message in this context, depending on the interfaces resulting from PSR-7. My point is that @codeguy is working on an implementation that I'd like to point to from a documentation perspective. Also I'm using Route heavily day to day so I'll need an implementation pretty quickly for my own use :-)

[codeguy]

@hannesvdvreken Yep, we all have the same goal. Everything will be coded for PSR-7 interfaces and not particular implementation of such.

[philipobenito]

That was always the aim with Route, ideally to write an application that was properly agnostic of it's framework/bootstrap, I want people to be able to move away from League\Route if they want to, and with the look of what @codeguy is doing with Slim 3, it would be minimal work to drop an app built on this router straight in to Slim and for it to work, first example of the FIG stuff working in the wild hopefully, which I'm kind of excited about.

[codeguy]

@philipobenito I'm pretty sure I'm going to use Route in Slim 3... if it doesn't support PSR7 by release date, I'll just write a quick strategy for it.

[philipobenito]

@codeguy that's fantastic news, if you need anything from me just shout, even if that be a specific tag for you to use until the PSR is official

[codeguy]

@philipobenito Pushed an experimental branch for you to review that integrates League/Route. You'll want to look at these files specifically:

• https://github.com/slimphp/Slim/blob/develop-route/Slim/Router.php
• https://github.com/slimphp/Slim/blob/develop-route/Slim/RouteStrategy.php
• https://github.com/slimphp/Slim/blob/develop-route/Slim/Route.php
• https://github.com/slimphp/Slim/blob/develop-route/Slim/App.php#L245

[hannesvdvreken]

@philipobenito: 👌 pointing to an implementation from docs. We're on the same page then ;-)

[philipobenito]

All looks good @codeguy, I wrestled with the idea of catching not found etc within the strategy but settled on the opinion that it's better outside of there for the user to decide what to do. Will you be exposing the container or continuing with Pimple like it says in your blog post?

[codeguy]

May as well move over to League/container to reduce dependencies.

[philipobenito]

Ok so I'm planning a simplification of the API which will probably be much better for you, we can discuss what changes I have planned before release. Do you have a release date you're aiming for then I can aim to get v2 of both packages ready for then? Route won't be changing much at all, just the dependency change and a possible filesystem caching layer for defined routes so that it's not interacted with every request (this is something built in to FastRoute). Container again isn't gonna be changing in terms of functionality, just a big internal tidy up and improving the cohesiveness between features.

[codeguy]

No hard release date yet.

[philipobenito]

Ok, well I'll be starting my planned works the next couple of days and shouldn't take me too long so I'll keep you updated to public changes.

[codeguy]

👍

[codeguy]

@philipobenito Not sure if your changes will include this or not, but can you create a new tag/branch that does not have the Symfony HTTP Foundation dependency in composer.json? No immediate rush.

[philipobenito]

Yeah, I'll create you a branch later tonight and alias a packagist tag to it then any specifics for Slim can be put in there

[philipobenito]

@codeguy hopefully this will help for now, http exceptions and and json responses will be broken for now but will fix that tomorrow 1f97cd5

[codeguy]

@philipobenito After some experimentation, I've found it's going to be easier and cleaner to use FastRoute directly. However, I'm definitely going to extract the PSR-7 stuff into a separate component and do what I can to advertise and help league/route.

[philipobenito]

@codeguy That makes sense based on what you're doing, look forward to the PSR-7 package though, aiming to get that implemented asap.

[sagikazarmark]

@codeguy @philipobenito are you sure that stackphp will rely on PSR-7? Because I heard other news. I was also thinking about creating a middleware package for PSR-7, because phly/conduit is not really what I imagine as the clone of stackphp.

In the meantime check phly/http which is a HTTP Message implementation created by the editor of the PSR.

[sagikazarmark]

Some update: PSR 7 is out. There are already a few implementations out there, the most sane ones:

• phly/http
• guzzle/psr7

They both provide the psr/http-message-implementation virtual package.

[philipobenito]

@sagikazarmark v2 is due soon and will depend on the abstractions but not provide an implementation by default. It will simply suggest several alternatives and the documentation/skeleton applications will handle the implementation details.

[sagikazarmark]

The provided virtual package is great for both directly requiring or suggesting.

[sagikazarmark]

I would probably extract the PSR7 part from the main package and move it to a separate one so that you can require the virtual package instead of suggesting it.

[ojhaujjwal]

I agree with @sagikazarmark about moving PSR7 implementation to a separate package!

[shadowhand]

@philipobenito do you want me to work on a PR for this?

[philipobenito]

It's actually already being worked on for v2, was waiting for the vote to pass before finalising but thank you.

Sent from my iPhone

On 21 May 2015, at 17:19, Woody Gilk [email protected] wrote:

@philipobenito do you want me to work on a PR for this?

—
Reply to this email directly or view it on GitHub.

[shadowhand]

@philipobenito when can we expect to see a branch?

[dolfelt]

@philipobenito Which implementations are being suggested going forward using PSR-7 with Route?

[philipobenito]

It will be completely up to the user which implementation is used but there will be a section in the docs to outline options.

Sent from my iPhone

On 21 May 2015, at 17:41, Daniel Olfelt [email protected] wrote:

@philipobenito Which implementations are being suggested going forward using PSR-7 with Route?

—
Reply to this email directly or view it on GitHub.

[philipobenito]

Next 1-2 weeks

Sent from my iPhone

On 21 May 2015, at 17:37, Woody Gilk [email protected] wrote:

@philipobenito when can we expect to see a branch?

—
Reply to this email directly or view it on GitHub.

[sagikazarmark]

It seems that the complete replace of Symfony HttpFoundation might not be necessary:

http://symfony.com/blog/psr-7-support-in-symfony-is-here

To preserve compatibility (for example with Stack based applications, like Proton) this compatibility layer could be used.

For the record I suggest preserving compatibility next to the new, PSR-7 strategy which should be the recommended one.

[philipobenito]

This has already been discussed on several threads and is being implemented for v2.

Sent from my iPhone

On 30 May 2015, at 21:04, Márk Sági-Kazár [email protected] wrote:

It seems that the complete replace of Symfony HttpFoundation might not be necessary:

http://symfony.com/blog/psr-7-support-in-symfony-is-here

To preserve compatibility (for example with Stack based applications, like Proton) this compatibility layer could be used.

For the record I suggest preserving compatibility next to the new, PSR-7 strategy which should be the recommended one.

—
Reply to this email directly or view it on GitHub.

[sagikazarmark]

Sorry, I didn't find any reference to symfony's compatibility layer. Also, it just have been released.

[philipobenito]

Less Symfony specific but the fact that strategies are going to be split out and HTTP Foundation will still be supported.

Sent from my iPhone

On 30 May 2015, at 21:33, Márk Sági-Kazár [email protected] wrote:

Sorry, I didn't find any reference to symfony's compatibility layer. Also, it just have been released.

—
Reply to this email directly or view it on GitHub.

[alexbilbie]

Hey @philipobenito where are you with this? Am happy to help with this

[philipobenito]

Hey man. Already done, just got some changes to make to Container before I release, next week some time for both v2 releases.

—
Sent from Mailbox

On Fri, Jul 24, 2015 at 6:28 PM, Alex Bilbie [email protected]
wrote:

Hey @philipobenito where are you with this? Am happy to help with this

Reply to this email directly or view it on GitHub:
#32 (comment)

[alexbilbie]

❤️

[mwillbanks]

@philipobenito any chance of creating a branch with some of this so that it can be exposed and some of us can start testing it?

[sagikazarmark]

👍 I am also curious about new features.

[hannesvdvreken]

+1