Adding support for this would be great, but there are some things to consider.
PowerShell doesn't scale very well. Adding global renderers could significantly impact performance. For the same reason adding Where-Object-like filters that determine if an attribute should be rendered by PowerShell isn't feasible
Probably best to stick to how StringTemplate does it by default, by type.
This is difficult to present in an accessible way from PowerShell
If it was a parameter it would need to be a hashtable and that hurts discoverablity.
Might be best as a separate Cmdlet, maybe Register-StringTemplateRenderer? Would this register globally or would it require passing a template group instance?
The implementation would likely be a custom AttributeRenderer implementation that stores registered type to scriptblock mappings and evaluates each attribute.
StringTemplate has support for adding custom renderers. These renders provide three things
For example, lets say you wanted
type
objects to render like they do in certain PowerShell format displays, you could create this renderer:If
Invoke-StringTemplate
was using that renderer you could do thisAdding support for this would be great, but there are some things to consider.
PowerShell doesn't scale very well. Adding global renderers could significantly impact performance. For the same reason adding
Where-Object
-like filters that determine if an attribute should be rendered by PowerShell isn't feasibleThis is difficult to present in an accessible way from PowerShell
hashtable
and that hurts discoverablity.Register-StringTemplateRenderer
? Would this register globally or would it require passing a template group instance?The implementation would likely be a custom
AttributeRenderer
implementation that stores registeredtype
toscriptblock
mappings and evaluates each attribute.