Feature request: mail function

[taophp]

Currently, I see no way to handle mailing within xtemplate. And I don't think any ambitious web site or app should avoid this nowadays. So I'm sharing my thoughts about it below. Please, let me know what you think.

• configuration: as the mailing able Caddy security module is very likely to be used with a user-centric xtemplate app, the smtp configuration should be share between the two modules (using snippet), so the configuration expected by xtemplate for this should use the same format as Caddy Security,
• a directive should be added to this configuration to handle mail templates directory (supporting T10N?)
• 2 new functions mail and mailWithTemplate should be added that should be used in templates (but not mail templates).

[infogulch]

This is a great idea!

I'm currently refactoring the dot context system to allow for start-time configuration of the dot value {{ . }}. This will unify the files context and db items so they are more configurable (including disabling entirely, or having more than one of each with different configurations), and will also allow for easier extensibility by importing a package that adds new functionality to the dot value. This is where I think mail functionality would fit best.

As for the Caddy integration, reusing the same configuration format as Caddy Security seems very reasonable. Caddy Security may be a good place to draw ideas for implementation as well.

[taophp]

Great ! Please, let me know how you progress on this!

[infogulch]

I have an update on the new dot value system.

Initially my plan was to use the reflect package to create a new struct at start time with (optionally) embedded fields configured by the user. This would give a nice UX where users could call methods on any of the embedded members directly, or prefix with the field name if ambiguous.

It turns out Go has very little support for creating structs with embedded members at start time. Here's some playground examples that show a few variations of what I tried:

• https://go.dev/play/p/CvHP9dJOGbc
• https://go.dev/play/p/EeWhO0_wljU
• https://go.dev/play/p/XRayDQjxwMl

This is a bit disappointing for me, and while its tempting to start yak shaving and submit implementation ideas on the upstream issue, for the sake of xtemplate it's probably best to accept that embedded fields are not feasible and just proceed with named fields. This hits the UX a bit, since all of the methods would have to be prefixed with their field name, but it's a small price to pay when the alternatives are "no user customization" and "wait until an issue from 2016 is fixed by the language". (And honestly there may be a clarity argument as well, since embedded fields are a moderately advanced Go feature.)

Long story short, if Go adds support for runtime embedded field methods then we'll have some options open to us in the future; until then I have a solid plan and a decent start at an implementation for xtemplate.