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

Look into supporting PSR-13 and PSR-7? #109

Open
voxpelli opened this issue Feb 9, 2017 · 3 comments
Open

Look into supporting PSR-13 and PSR-7? #109

voxpelli opened this issue Feb 9, 2017 · 3 comments

Comments

@voxpelli
Copy link
Contributor

voxpelli commented Feb 9, 2017

Just found out that there's a new standard interface for Link definitions from the PHP-FIG group, the PSR-13, which among other things mentions the Microformats link relation registry.

Thought it made sense to open a discussion here about how one could go about adding support for those interfaces within this library or within a companion library.

If one were to expose a method that would rather than an associative array return an actual object that wraps the parsed result, then that one could implement the Psr\Link\LinkProviderInterface and which in turn would expose link objects that implements the Psr\Link\LinkInterface.

Along the lines of that it could perhaps also make sense to support the PSR-7 and it's Psr\Http\Message\MessageInterface / Psr\Http\Message\ResponseInterface as well for interfacing with responses from already made requests, such as ones made by eg. Guzzle, Symphony, Drupal (I think) etc.

PSR-7 support could be achieved by making Mf2/parse() accept, in addition to the string it accepts today, an object implementing the Psr\Http\Message\ResponseInterface interface and when given such an object it could get the HTML content from that.

Mf2/parse() could also look for a Psr\Link\LinkProviderInterface on such an object and when given it could skip parsing any HTTP-headers for link-relations and rather just expose the links given there.

I know this sounds like a lot of plumbing, but I love the work the PHP-FIG is doing. I mean: They managed to even get Drupal to start using code from the rest of the community and right now the only major PHP-project I know of that isn't part of and supporting PHP-FIG is WordPress (which isn't too suprising). But Symphony, Drupal, Zend Framework, Magento and many more are part of it so making ones library interface with that code in one way or another would make it feel like a much more integral part of the overall PHP community.

Any thoughts?

@aaronpk
Copy link
Member

aaronpk commented Apr 25, 2017

We might need to do this as a companion library for the time being. We're trying to stay backwards compatible with pretty old versions of PHP for the sake of being able to be used in Wordpress, so some of the language features don't exist in 5.4.

@barnabywalters
Copy link
Collaborator

barnabywalters commented Jun 6, 2021

I just had a similar thought and wondered if someone had already bought it up!

I haven’t looked into the LinkProvider stuff in detail, but regarding supporting Mf2\parse() et al accepting an instance of Psr\Http\Message\ResponseInterface, that should be quite easily possible without breaking back compat or requiring any external libraries. Something like:

function parse($input …) {
  if (interface_exists('\Psr\Http\Message\ResponseInterface') && $input instanceof \Psr\Http\Message\ResponseInterface) {
    $url = $input->getEffectiveUrl();
    $input = $input->getBody()->getContents();
  }
  …
}

AFAIK this should work on PHP 5.4 — or at least, we can gate any non-5.4 compatible parts with checks. Any strong opinions about this?

@barnabywalters
Copy link
Collaborator

barnabywalters commented Jun 6, 2021

Hmm on closer inspection, it looks like the PSR-7 ResponseInterface doesn’t have any way of getting the effective URL, which makes it pretty useless for this case. We could still accept a ResponseInterface for $input, but it would always additionally require the $url parameter to be set. That’s unfortunate. What a ridiculous regression.

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

3 participants