At template runtime, there are a number of pieces of information that could be useful to the developer that are not accessible within the current HTML Template models. These include:
- recipient email address
- T_TEMPLATE_QUEUE.id
- T_TEMPLATE.id
-- most importantly, and less importantly (but still potentially useful with some imagination) --
- Email profile ID
- Synchronous or Queued
- Called method (i.e. Templates/RenderConstituentInfo, Templates/GetConstituentInfo, Emails/SendConstituentInfo)
Some of these should be nullable (since templates can be rendered outside the context of an actual email to be sent), but the Templates methods would need to be expanded to accept these parameters, and the application similarly would need to be modified to send those parameters.
The chief use case here is a functionality gap whereby you cannot accurately render "this email was sent to joeuser@example.com", say, in an email footer, because @Model.ElectronicAddress.Address is always the Constituent's primary eaddress, even when the email is being sent (via API method or ticket order acknowledgement window in the client) to someone else. Working around this is tremendously difficult to do successfully.