Include partials

[loopmode]

Hi. We're using your library to preview html email templates. A small stack that we feed with some json data and out comes the html email in a browser. This works great.

However, a new requirement came up and we have to actually include partials in various templates.

The way I see it, when we put a <#include "foo.ftl"> in a template, it simply remains exactly that string - it doesn't get evaluated and the contents of foo.tpl don't get included.
Effectively, we can preview each partial on its own, but we can not preview the composed email template.

Without going into details - should this be possible, and we just need to setup our stack better? Or is it maybe just not possible without using actual java freemarker?

[int64ago]

Hi, we use fmpp under the hood, it seems include is supported by fmpp. But we don't use this in our work anymore, it's very pleasure if you could raise a PR :-)

[loopmode]

Hi. I'm not sure I will be able to spend more time and provide a PR, but here my findings for future reference.

I think the problem is simply with the random filenames being used, but it might also involve copying /providing files.

This is how I was able to see the includes actually working:

hard-coded external includes in the config object of node_modules/freemarker/dist/app.js renderProxy function:

var config = {
    // ...
    freemarkerLinks: `{
        templates: C:/absolute-path/to/templates
    }`
};

In that template folder I have foo.ftl and bar.ftl, with foo including bar via

<#include "/@templates/bar.ftl">

With that, the include statements are evaluated just fine and I can preview the resulting template correctly. So the feature is indeed supported and available.

My guess is that we would have to

• provide access to the entire context that contains the templates, but possibly built and not source
• either map/translate actual filenames to random filenames, then update/replace the filenames in <#include "filenename"> statements
• or stop using random filenames, this might be easier. If avoiding collision was the only purpose of random filenames, we could use a temp folder with a random name but original filenames inside.

I think that for now, I will try to solve the problem within the scope of my project, and in a rather specific way. If I come up with something useful, I'll see if it can be integrated at the level of this library.