Just a quick follow-up:
We were thinking about how to make some “implementation specific options” available to the manipulators.
These options could be Imagine Image Quality, some Remote Service API Key, …
One solution would be to inject those settings into the manipulators (or use some service with the settings injected).
But we were looking for ways to avoid these “Global contexts” and there are some reasons for this:
- Make the manipulators more self-contained
- …and easier to test
- Allow different “presets”, e.g. use Service A in one context and Service B in another
In order to keep the core API slim, we came up with following approach:
Add an untyped options
array to the BlobMetadata
that can contained any prefixed(!) options, for example:
<?php
$metadata = new BlobMetadata('image/png', 'someFile.png', ['Neos.Imagine' => ['jpeg_quality' => 80]]);
Some default factory could create the metadata object and inject some options configured via Settings, for example:
Kitsunet:
ImageManipulation:
defaultOptions:
'Neos.Imagine':
'jpeg_quality' => 80
Questions:
- Maybe use the composer package key as namespace instead?
- Is
BlobMetadata
the right name now that this is more of a “Manipulation context” (that can even be replaced by individual manipulators)?
Note: I’m just writing down what we discussed yesterday (or what I took away from it) for the record. All credit to @christianm, I haven’t written a line of code