Twig templates and hook_format_strawberryfield_twigcontext_alter functions don't know who is calling them

[patdunlavey]

It would be useful to have a value in the $context variable that is passed to the \Drupal\format_strawberryfield\Entity\MetadataDisplayEntity::renderNative and \Drupal\format_strawberryfield\Entity\MetadataDisplayEntity::processHtml functions which indicates who is calling them. This would also be valuable to have prior to \Drupal::moduleHandler()->alter('format_strawberryfield_twigcontext', $context);

A couple use cases:

1. A user wishes to use the same metadatadisplay template for MODS export as for OAI, but when it's OAI, needs to not render the xml wrapper elements.
2. A users wishes to add/alter elements in the $context when running AMI, but not when displaying object metadata.

[DiegoPino]

@patdunlavey this makes sense.
But I need to think about a formal (means a correct key/value set) way of implementing this that also adds some extra data. Given that context is becoming a thing I should also push extra data (e.g URL) into this.

[patdunlavey]

Some thoughts for possible approaches:

1. In all cases where a twig $context is initialized, include something like $context['twig_context'][] = 'some value';
2. In all cases of \Drupal::moduleHandler()->alter('format_strawberryfield_twigcontext', $context), perhaps include the calling class and method as a separate argument? E.g. \Drupal::moduleHandler()->alter('format_strawberryfield_twigcontext', $context, __CLASS__, __METHOD__)?

Currently, hook_format_strawberryfield_twigcontext_alter is invoked in:

• format_strawberryfield/src/Plugin/Field/FieldFormatter/StrawberryPagedFormatter.php
• format_strawberryfield/src/Plugin/Field/FieldFormatter/StrawberryMetadataTwigFormatter.php
• format_strawberryfield/src/Plugin/Field/FieldFormatter/StrawberryCitationFormatter.php
• ami/src/Controller/AmiRowAutocompleteHandler.php
• ami/src/AmiUtilityService.php
• format_strawberryfield/src/Controller/MetadataExposeDisplayController.php

[DiegoPino]

@patdunlavey I will have a global pull against every module by this Friday. I will limit the passed data to a common SBF context key but will also expose Request (HTTP) info. I think I will excuse myself (safety/also too cryptic) of passing which class originate the call. That almost feels outside of the scope of a template developer (as a role)