Integrate formatters into the architecture

[Bilge]

This ticket is an open discussion about whether there is a good way to integrate formatters into the architecture. Data might flow through objects in the following order.

Connector → Formatter → ProviderResource

However, we need to understand what the interface for Formatter must be and how it integrates into the rest of the system in a meaningful and reusable way.

[a-barzanti]

Basically if you have connector that is not a network resource, but another kind of data source you should use a formatter instead of a resource, at this point can we define the Formatter as an extended Resource, with a kind of selector in the constructor (to identify the source from the connector)?

[a-barzanti]

Also if we want the formatter to be generic, we shouldn't have getProviderClassName and getProviderTag to be defined, but rather have the values passed in the constructor.

[Bilge]

@a-barzanti You appear to be talking about the ProviderResource interface but the Formatter interface would not share any similarity. I imagine formatters would look something like the following.

interface Formatter
{
    /**
     * @param mixed $data Arbitrary data.
     */
    public function format($data) : \Iterator;
}

I am not sure if the return type should actually be Iterator or just mixed data. I am also unsure how formatters should integrate with resources and connectors at this time.

[a-barzanti]

If you have a formatter the ProviderResource will always be the same, so instead of feeding the Formatted data to the resource why not replace the resource with the formatter.

[a-barzanti]

So for the CSV for instance in the specification you can simply write: new CsvFormatter($csvFile, CsvProvider::class);

[Bilge]

If you have a formatter the ProviderResource will always be the same

This is incorrect. A formatter and a resource have different responsibilities. A formatter takes raw data and transforms it into a format suitable for consumption by a resource. A resource's responsibility is to present that data as an enumerable series of arrays, if it isn't already.

In some cases, you are right, the formatter has already presented the data as an enumerable series of arrays. This might be the case for JSON formatters, for example. However, other formats may require additional processing.

Even if formatters were required by the interface to always produce an enumerable series of arrays, sometimes resources have to do additional tasks, such as spooling and aggregating paginated results. That is, if the provider must be called several times to fetch the full set of results, it is the responsibility of the resource - not the formatter - to make several requests using the connector to fetch the complete results set.