It being under the FIG name in no way prevents or discourages anyone from "trying it out" if they wish, and the Review period (current status) is exactly for further "try it out". FIG 3's Review period includes an explicit requirement for it.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/62449748-94bb-1d0b-5aa5-d531540fe75b%40garfieldtech.com.
>> 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:
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myUZ4XH6mG4pNnXfGKavnAhdxN6fMocVngpxmNT6TLi8yA%40mail.gmail.com.
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 <mweiero...@gmail.com> wrote:
On Sep 12, 2016 5:31 PM, "Daniel Hunsaker" <danhu...@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+u...@googlegroups.com.
To post to this group, send email to php...@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.
On Tue, Sep 13, 2016 at 2:50 PM Larry Garfield <la...@garfieldtech.com> wrote:
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:
Thanks for taking the time to reply.$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.
I don't think I've made myself clear. My contention is that LinkableResponse is not *a collection of links*, rather, it *has* a collection of links. It should not implement LinkCollectionInterface at all. Does this make sense? I fully appreciate that you and Matthew are smart guys who understand that interfaces are analogous to *is a* and not *has a* semantics, but I feel that this spec is currently overcomplicating things a bit.
--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0e9c9b93-880b-a705-69d4-bd7746eddf94%40garfieldtech.com.
--Larry Garfield
--
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+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9472b271-fbe9-439f-8a38-17023bd53aa2%40googlegroups.com.
I suppose "container" is too loaded a term... as is "sixpack" :-D
I'm cool with collection, as a "collection of collections" is no more odd to me than an array of arrays.
CRB
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9472b271-fbe9-439f-8a38-17023bd53aa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/875a9f23-e4cd-bce4-a404-30f3c570558d%40garfieldtech.com.
ListCollectionInterface - It's rather filtering data interface so it could be replace with LinkFilterInterface.
Collection and Provider are too abstract names for this small and simple interface. Filter it's a common word and will fit to the collection and provider implementations.
Krzysiek Piasecki
On 10/15/2016 12:35 AM, Krzysiek Piasecki wrote:
No, filter implies that it's an object whose purpose is to take an input
set and return a smaller output set.
That's not at all what
LinkCollection/LinkProvider is for. It's to indicate an object which
carries and contains links, but potentially other stuff as well.
As coordinator of "PSR-13: Link definition interfaces", I hereby
officially place the proposal in Review status. Review will end no
earlier than 17:22 on 29 August 2016.
The specification may be found here:
- https://github.com/php-fig/fig-standards/blob/master/proposed/links.md
with a metadocument covering background and decisions here:
- https://github.com/php-fig/fig-standards/blob/master/proposed/links-meta.md
Please take some time to review the proposed standard.
As a reminder, during the review period, we may incorporate minor
changes, but no substantive changes. If you have a suggestion for a
substantive change, please open a thread to discuss it, so we can
determine whether we need to return to Draft status to address the
change, or whether we will choose to move forward.
Thanks in advance!
--
Matthew Weier O'Phinney
mweiero...@gmail.com
On Nov 1, 2016 2:51 AM, "Niklas Keller" <nicks.po...@gmail.com> wrote:
>
> I guess I'm too late. Is there any reason to use the abbreviated `getRels()` and `withRel()`, but the long form for attributes (`getAttributes()`)? Feels inconsistent. I'd prefer `getRelation()` as well.
Yes, and it was asked previously: both HTML and several JSON specifications use the shortened form "rel". This spec mirrors those.
> On Monday, August 15, 2016 at 7:22:20 PM UTC+2, Matthew Weier O'Phinney wrote:
>>
>> As coordinator of "PSR-13: Link definition interfaces", I hereby
>> officially place the proposal in Review status. Review will end no
>> earlier than 17:22 on 29 August 2016.
>>
>> The specification may be found here:
>>
>> - https://github.com/php-fig/fig-standards/blob/master/proposed/links.md
>>
>> with a metadocument covering background and decisions here:
>>
>> - https://github.com/php-fig/fig-standards/blob/master/proposed/links-meta.md
>>
>> Please take some time to review the proposed standard.
>>
>> As a reminder, during the review period, we may incorporate minor
>> changes, but no substantive changes. If you have a suggestion for a
>> substantive change, please open a thread to discuss it, so we can
>> determine whether we need to return to Draft status to address the
>> change, or whether we will choose to move forward.
>>
>> Thanks in advance!
>>
>> --
>> Matthew Weier O'Phinney
>> mweiero...@gmail.com
>> https://mwop.net/
>
> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/bb9283a5-331e-41d7-af82-fcb56353664c%40googlegroups.com.