Introducing php kit api v2

[srenault]

No description provided.

[gsteel]

Please could we make the minimum PHP version 7.1? Usage of 5 is dwindling and the shiny stuff in 7.1 such as nullable type hints and return types are too good to miss out on ;)
I can't believe that anyone investing time in working with Prismic in PHP is stuck on 5.
It also makes sense to adopt PSR-6 Cache so that there's no need to implement the proprietary cache interface.

[srenault]

Remove this line so

[gsteel]

The link resolver is quite an important concept and generally represents code that you must write to effectively work with the API. Whilst there's nothing wrong with reducing the idea to a callable, would it not be better to force the user to satisfy an interface at least so that it's clear what you need to do when consuming the kit?
Also reducing the link resolver to a callable gives you no clue as to what arguments that callable might receive - In the past, whilst not enforced, you could generally rely on this to be a document or link fragment…

[gsteel]

One of the benefits of having a Document class was the ability to easily inspect the doc for certain properties in the content model like

if ($document->get('myProperty')) {
    echo $document->get('myProperty')->asHtml();
}

With the removal of the Document class and all associated fragments, we've got a bunch of stdClass instances so our code will now look like:

if (isset($document->myProperty)) {
    echo SomeClass::SomeStatic($document->myProperty);
}

That's mostly fine, but when the JSON is unserialized, there's every chance that your document model will have properties you can't easily reference, like anything with a dot, space or dash, so in PHP we'd have to do this:

echo $document->{"foo.bar"};
echo $document->{"foo-bar"};
echo $document->{"foo bar"};
// etc…

I know that the JSON editor will not allow a dot, but dashes and spaces are currently legal in property names AFAICT.

What is the main goal of this rewrite? At the moment, it doesn't look like it's making working with the API easier in any way. It's nice to not have to reference all properties with the document type, like type.fragmentName

If Prismic is all about working with content models, it makes more sense to me to retain the document model and expand it so that you can hydrate document types or result sets/responses to specific classes making templating easier and safer, idk, something like…

if ($article->hasTitle()) {
    echo $article->getTitle(); // Where article already has an injected instance of \Prismic\LinkResolverInterface
}

Furthermore, providing a framework around serialising to HTML with out of the box sane defaults and interfaces we can implement when the serialisation process needs to be changed in whatever way…

[gsteel]

I don't get it! Has there been any discussion with any other customers that use the PHP kit? Every comment I've left on this pull has gone unanswered and there's been no discussion on Slack AFAICT. Is there a plan?

[srenault]

@gsteel We merged this in order to publish a beta version. We can still release another versions over it. We're going back to you about your comments pretty soon.
Sorry for the bad communication.