Feature Request: Allow mapping files/file paths to file types/processors

[d-s-codappix]

One might also provide an option to map files/file paths to file types. E.g. we have different renderings for elements, e.g. HTML as well as XML (for some exports).
That way our content elements have both, an Element.html and Element.xml file, while both are Fluid.
Right now fractor will handle the xml files as xml, e.g. add <?xml version="1.0"?> and sometimes completely remove the actual fluid content of the file.

An option to map these files to fluid might be a good idea. We also have projects with Element.pdf in combination with bithost-gmbh/pdfviewhelpers package.

Is this fine as a comment, or should I open another

[chrissonntag]

I have just submitted a PR 338 that allows the user to customize the allowed file extensions for at least the Fluid, TypoScript, Xml and Yaml File Processors. And also PR 339 which allows to skip certain File Processors, thus given one the option to steamline a testing scenario.
One possible solution to the matter of testing specific files with specific File Processors would be to have a Fractor Config for each scenario with different restrictions:

Example 1

Have a config file the might be called test-fluid.fractor.php:

<?php

declare(strict_types=1);

use a9f\FractorFluid\Configuration\FluidProcessorOption;
use a9f\FractorHtaccess\HtaccessFileProcessor;
use a9f\FractorTypoScript\TypoScriptFileProcessor;
use a9f\FractorXml\XmlFileProcessor;
use a9f\FractorYaml\YamlFileProcessor;

return FractorConfiguration::configure()
    ->withPaths([getcwd() . '/**/*'])
    ->withSkip([
        '*/node_modules',
        '*/vendor/*',
        HtaccessFileProcessor::class,
        TypoScriptFileProcessor::class,
        XmlFileProcessor::class,
        YamlFileProcessor::class,
    ])
    ->withSets([
        Typo3LevelSetList::UP_TO_TYPO3_12,
    ])
    ->withOptions([
        FluidProcessorOption::ALLOWED_FILE_EXTENSIONS => ['xtml', xml'],
    ]);

Example 2

And then have another config file called test-xml.fractor.php that might look like so:

<?php

declare(strict_types=1);

use a9f\FractorFluid\FluidFileProcessor;
use a9f\FractorHtaccess\HtaccessFileProcessor;
use a9f\FractorTypoScript\TypoScriptFileProcessor;
use a9f\FractorXml\Configuration\XmlProcessorOption;
use a9f\FractorYaml\YamlFileProcessor;

return FractorConfiguration::configure()
    ->withPaths([getcwd() . '/**/*'])
    ->withSkip([
        '*/node_modules',
        '*/vendor/*',
        FluidFileProcessor::class,
        HtaccessFileProcessor::class,
        TypoScriptFileProcessor::class,
        YamlFileProcessor::class,
    ])
    ->withSets([
        Typo3LevelSetList::UP_TO_TYPO3_12,
    ])
    ->withOptions([
        XmlProcessorOption::ALLOWED_FILE_EXTENSIONS => ['xml', 'xlf'],
    ]);

@d-s-codappix Do you think this is viable and could work for you? Or do you have any suggestion on how to address this issue from another perspective?

[d-s-codappix]

Hey @chrissonntag thanks for investing, glad to see some efforts.

Well I guess I've described our use case. Your proposal seems like it might work, e.g. I could imagine the following configuration for our use case, based on your proposal:

<?php

declare(strict_types=1);

use a9f\FractorFluid\Configuration\FluidProcessorOption;
use a9f\FractorHtaccess\HtaccessFileProcessor;
use a9f\FractorTypoScript\TypoScriptFileProcessor;
use a9f\FractorXml\XmlFileProcessor;
use a9f\FractorYaml\YamlFileProcessor;

return FractorConfiguration::configure()
    ->withPaths([getcwd() . '/packages/**/Resources/Private/**/*'])
    ->withSkip([
        HtaccessFileProcessor::class,
        TypoScriptFileProcessor::class,
        XmlFileProcessor::class,
        YamlFileProcessor::class,
    ])
    ->withSets([
        Typo3LevelSetList::UP_TO_TYPO3_12,
    ])
    ->withOptions([
        FluidProcessorOption::ALLOWED_FILE_EXTENSIONS => ['html', xml', 'pdf'],
    ]);

The only complaint: This doesn't feel intuitive. We would need to add more and more files, instead of having a single configuration file.
Also one would need to add all possible processors, except one, to the withSkip() call.
It might be nicer to have an approach within the existing configuration. This could look like the following:

return FractorConfiguration::configure()
    ->withPaths([getcwd() . '/**/*'])
    ->withSets([
        Typo3LevelSetList::UP_TO_TYPO3_12,
    ])
    ->withOptions([
        FluidProcessorOption::ALLOWED_FILE_EXTENSIONS => ['html', xml', 'pdf'],
        FluidProcessorOption::ALLOWED_FILE_PATHS => [getcwd() . '/packages/**/Resources/Private/**/*'],
    ]);

But I'd be happy if the feature is available, and I can understand if my approach would be too much effort, leading to following your approach.

[chrissonntag]

Morning, you're absolutely right about the counter-intuitivity and your proposal would present a kinda smooth solution. Only thing is, and that's what I was worried about, that it might need an overhaul of how Fractor gathers and handles its configuration. Also one could argue that an option FluidProcessorOption::ALLOWED_FILE_PATHS would make the general path setting ->withPaths([getcwd() . '/**/*']) obsolete - or at least kind of redundant. I'm not quit sure how to go about this.

@simonschaufi What do you think? Removing the latter one would stand a breaking change and should be avoided anyway. We could simply create a paths bucket for every Processor (if configured) and see if the current file's path to be processed is in the general defined paths. Then skip the current file if there is no match.