The standard example we've been using is a domain object of some sort
that then is getting rendered to an HTTP Response. To wit:
$article = load_article(...);
// Article is a class in a domain model, but can generate links to other
articles such as next/prev, up to the index of articles, etc.
// ...
// LinkableResponse is an implementation of PSR-7 ResponseInterface and
LinkCollectionInterface
$r = new LinkableResponse(200);
// Whatever app-sensitive rendering logic applies, not our problem.
$r = $r->withBody(new StringStream(render($article));
// The links on article are generated on the fly here,
// based off of the underlying data of article, whatever that is.
foreach ($article->getLinks() as $link) {
$r = $r->withLink($link);
}
Forcing both Article and Response to be traversable on links is a no-go,
as they may have other data sets in them that would make just as much
sense to iterate. But it makes total sense for Article to be able to
provide links (read only) and Response to both accept them and be able
to return them (or turn them into HTTP headers directly, or whatever
else someone feels like doing). Neither Response nor Article are
PSR-13-specific concretions.
--Larry Garfield
On 09/13/2016 08:18 AM, Josh Di Fabio wrote:
Quoting the meta doc.
> Why is a LinkCollectionInterface needed?
> In many contexts, a set of links will be attached to some other object. Those objects may be
used in situations where all that is relevant is their links, or some
subset of their links. For example, various different value objects
may be defined that represent different REST formats such as HAL,
JSON-LD, or Atom.
In my opinion, "some other object" should not be defined by this spec.
What use is an interface for an object which simply "has a collection
of links"? What if that object has multiple accessors for different
kinds of links? I don't see any value in this spec attempting to
define what such objects should look like, so I'd be interested to see
a concrete example of why it is useful (apologies if I missed this in
the meta doc).
I would propose either removing the collection interface or making it
a true and useful collection object instead of what we have now.
Here's a suggestion:
interface LinkCollectionInterface extends \IteratorAggregate
{
public function getIterator(): Iterator;
public function filterByRel($rel): LinkCollectionInterface;
}
It would seem better to then replace these interfaces with concrete
implementations, since they are clearly fairly simple value objects,
but from what I can remember it's in your bylaws only to define
interfaces.
On Mon, Sep 12, 2016 at 11:52 PM Matthew Weier O'Phinney
<mweierophin...@gmail.com <mailto:mweierophin...@gmail.com>> wrote:
On Sep 12, 2016 5:31 PM, "Daniel Hunsaker" <danhunsa...@gmail.com
<mailto:danhunsa...@gmail.com>> wrote:
>>
>> >> I'd expect an object implementing a CollectionInterface to
be iterable and
>> >> to already contain the items in question. The current
implementation of the
>> >> LinkCollectionInterface though looks more like a
CollectorInterface.
>> >> Something that collects linkInterfaces and can return a
>> >> LinkCollectionInterface.
>>
>>
>> Matthew and I brainstormed a bit more. The only other word we
could
>> come up with that we didn't hate even more than "Collection" was
>> "Catalog". Which would then result in:
>
>
> Not against Catalog, personally. However, Andreas did mention
Collector as an alternate; is that one of the more-hated
designators that were considered? That wasn't clear from the
above paragraph...
I was hesitant about it, as it implies that the instance is
collecting instances for purposes of returning a collection, which
brings us back to the original naming issue.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/1f87a36c-35e2-5129-88a7-a5193dc2c27b%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
