Template path for generated email

[igbanam]

I generated an email in an app with

marten gen email SomeEmail --app nested

The files generated were

src/nested/emails/some_email.cr
src/nested/templates/nested/emails/some_email.*

I expected the templates to be at

src/nested/templates/emails/some_email.*

[ellmetha]

Hey! 👋

I converted this to a discussion given that this is not a bug. What you are describing is the expected behaviour: generated app templates are namespaced to their associated app name.

If you were to render your template, you would currently refer to it using the path nested/emails/some_email.html. With your proposal, the app namespace would be removed, and you would refer to your template using emails/some_email.html. The issue with this new path is that it's not namespaced, increasing the risk of naming conflicts, as different apps could easily use the same template name. This is why generated app templates are always namespaced: to ensure unique and clear identification, and to avoid potential conflicts.

[igbanam]

This tells me apps in Marten are not properly encapsulated. I expected that being in some , if I refer to an email (or any other resource, really) I should be referring to the resource within the ; unless otherwise explicitly stated — which should be discouraged. From this, it seems like templates can reach into any app in the project and render that.

Writing this now, I realize I've been doing extend "base.html" from everywhere.

Question I have are…

1. f Marten has emails namespaced this way, what's the benefit of keeping the email templates in the app?
2. How does Marten choose between src/app_1/templates/app_1/emails/some_email.* and src/app_2/templates/app_1/emails/some_email.* — hypothetical scenario, yes; but recipe for a lot of confusion in the future.

p.s: I know the marten gen tooling should abstract a lot of these concerns; but I have been typing out everything by hand until recently when i found out about marten gen

[ellmetha]

This tells me apps in Marten are not properly encapsulated.

They are manually and explicitly encapsulated. It seems you were expecting some sort of implicit encapsulation, but that's not how templates work in Marten. The gen management command enforces a set of best practices, and defining explicitly namespaced templates is one of them. This does not prevent one from disregarding this practice and changing this structure obviously. 🙂

f Marten has emails namespaced this way, what's the benefit of keeping the email templates in the app?

If templates are specific to the app in question, then this is simply aligned with the fact that app folders hold all the entities that are specific to them (models, schemas, templates, etc). Additionally, your app could be packaged and provided as a dedicated shard, so in this situation, the app's template folder will hold all the templates leveraged by the application and there won't be other places to put the templates. Obviously, you can define a project with multiple apps and centralize all the templates in a single folder if you wish (there is nothing inherently wrong with this approach, this is just not how apps are organized by default).

How does Marten choose between src/app_1/templates/app_1/emails/some_email.* and src/app_2/templates/app_1/emails/some_email.* — hypothetical scenario, yes; but recipe for a lot of confusion in the future.

Marten templates are loaded by going through a list of "template loaders". Given a template name "path/to/template.html", we go through all these loaders and we return the template that is found by the first loader that provides a result for the given path. One of these loaders is an "app loader" which works in a similar way: given a template path, the first result found while iterating over all the applications is returned.

This is why namespacing is important in any case in order to avoid naming conflicts with other applications. Non-namespaced template names should ideally be reserved for shared templates (such as a "base.html" layout, or partial templates that are meant to be included).