Allow for extending supported asset types

This is causing issues with integration with Acquia DAM for our client. I can look to provide patches, but I need to understand from the maintainers the reasoning behind the use of "final" on these classes, and what the correct path to allow for extending is in the minds of the maintainers.

I need to understand from the maintainers the reasoning behind the use of "final" on these classes, and what the correct path to allow for extending is in the minds of the maintainers.

Over time, we've found that customers will override classes throughout modules, if they can, which causes headache in the future when even simple changes are made. This requires new major versions to be created, which has a knock-on effect to downstream modules, making upgrading more difficult, especially custom code on customer sites.

That is why, except where we explicitly want to expose the API at a class level, we mark classes as Final. That way, when a customer request, like this one, comes in, we can make informed architectural decisions.

Luckily, as part of our download/sync work, we noticed that the hard coded derivatives were not sufficient. Instead of expanding their use within a single, non extensible class, a new plugin framework was introduced that allows us (and the original author of this post!) to add functionality without needing to change the signature of the underlying Asset and AssetDeriver classes.

Asset Media Source Plugins

Under Drupal\acquia_dam\Plugin\media\acquia_dam you'll find that all of our Asset types are separated into new plugins.
You can create a new Annotation like the following:

 * @AssetMediaSource(
 *   id = "audio",
 *   label = @Translation("Acquia DAM: Audio"),
 *   default_thumbnail_filename = "generic.png",
 *   asset_search_key = "ft",
 *   asset_search_value = "audio",
 * )

The plugins we use extend MediaSourceTypeBase -- which is public for customers to extend as well. In it are 3 variables:

• $embedCodeAssetField -> This is the default embedcode that goes in all Asset types, and required even for Download/Sync as the Media Library uses this field for thumbnail display.
• $localFileAssetField -> Used for local file assets. There is an example in the image plugin where the default managed file field is replaced with the imagefield.
• $assetFieldFormatterConfiguration -> An array of the field formatter configuration keyed by the field names for a particular Asset type. Each plugin can override this configuration for their own format. Even though the image plugin adds a new field, it'll get called as the active one because $localFileAssetField is overridden

The two main MediaSourceTypeBase class methods you'll be interested in is getActiveFieldName and getFormatter.
getActiveFieldName: This method gets the active field based on whether 'download assets' is checked or not. If you have a different workflow for your plugin, you could override this method to return a field regardless of the Asset configuration.
getFormatter: Gets the specific formatter settings from the assetFieldFormatterConfiguration dataset.

Hopefully this achieves what you're looking for here. Marking 'needs review' to get validation what we've built here meets your needs.

Marking fixed since this is in 1.1 now.