Allowing list files that contains a list of object (e.g. CSV)

[Tom32i]

The goal is to allow sources files that provides multiple objects, like CSV files, but also JSON and YAML, and one day distant sources like Google sheets.

stenope:
  providers:
    App\Model\Reference[]: '%kernel.project_dir%/content/references' // references.csv

[ogizanagi]

A bit anecdotic for the use-case but still: the second arg of trim is a list of chars to remove, not a string to remove.
Something like trimSuffix should be used instead: https://symfony.com/doc/current/components/string.html#methods-to-pad-and-trim

[ogizanagi]

I'm not quite confortable with tweaking the ContentManagerInterface::getContent signature to introduce an index specifically for this use-case. 😕
The ideal would be to keep the same interface, but dealing in the provider with the "index" concept as part of the slug.

The goal is to allow sources files that provides multiple objects, like CSV files, but also JSON and YAML, and one day distant sources like Google sheets.

Actually, I would consider such sources like a relational database table, somehow as we would do for a Doctrine DBAL provider: read a single table and use a column as the slug for each of the rows.

We could allow to configure the "column" (property) to use as the main identifier / part of the slug in a new provider type. Something like:

stenope:
  providers:
    App\Model\Reference:
      type: collection_file
      path: '%kernel.project_dir%/content/references.csv'
      id: id # Column/property to use as the slug for each row. Defaults to the row index?
      slug: 'reference-{id}' # Optional way to compose the slug with the id property as part of it. Defaults to the id property.

Usage:

$manager->getContent(Reference::class, 'reference-1');

The provider would require reading a single source file (perhaps allow merging together multiple files later),
but will implement ContentProviderInterface::listContents by creating a Content entry for each row.

This would require pre-decoding (but not denormalizing) the content from the provider, to extract each row of the file, but this would probably not impact performances much and could be easily cached on needs.

[Tom32i]

I agree with you, this is a draft and I was not fully happy with it :)