Add support for Freemarker

[ThijsTyZ]

It would be great if Muban could support other template languages, like Freemarker. We are currently using Muban for a Liferay project. Liferay uses Freemarker as template engine. If we would be able to use Freemarker in Muban it would be easier to use the templates in Liferay.

[ThaNarie]

Added a wiki page (with a link to the initial ticket) regarding template languages in Muban:
https://github.com/mediamonks/muban/wiki/Template-Languages

For Freemarker, I see 2 JS libraries:

• http://freemarker.js.org/
• https://github.com/kaola-fed/freemarker

And 2 webpack loaders:

• https://github.com/aixigo/freemarker-loader
• https://github.com/Justinidlerz/ftl-loader

All of them are using/calling Java under the hood, which makes it impossible for me to add any logic around the template files (e.g. partial comments, presets, including script/style tags in the templates).

Even if I could get it to work, the muban setup would be slimmed down and configured slightly different, but it could still be beneficial to these kinds of projects.

What are the exact benefits you are trying to gain for this implementation?
It's already possible to not use any of the templates and just compile the js/css to disk, but I assume you still like the benefit of working with FM templates in muban instead of Liferay itself? Because complication is quicker?

Would you be able to send me a few FM templates / partials so I can have a quick look to see if I can get anything to work?

[ThijsTyZ]

The biggest benefit would be development speed. Working in Liferay template themes is extremely slow. You need to build and deploy the theme in order to see the changes. This can take up to several minutes.
If we are able to fill in the Freemarker tags in Muban we can test them a lot quicker.

[ThaNarie]

Okay, so far I learned the following:

• Webpack loaders don't make sense in this context. Since everything JS is a small wrapper around calling Java (FMPP), there is no pre-compilation, which means no dynamic rendering from the browser.
• This means that everything needs to render in node, template + data = html. Which means it can also be done as a build+watch step, and serve the HTMl as static pages along side the webpack-dev-server.
• I picked a ftl 2 html lib (curerntly https://github.com/ntesmail/ftl2html) to just compile templates + data in HTML. Which works fine in a default setup.
• including and nesting partials work
• providing data in tdd files works as well, and it's possible to included nested tdd files for more dynamic control

Looking at some example Liferay template files, they contain a lot of Liferay logic:

• <@liferay.language key="site-pages" />
• <@liferay_util["include"] page=content_include />
• <@liferay_ui["menu"] menu=portletTitleMenu />

And some custom code that probably is provided as Java things:

• <#assign hotel = getHotelByCodeAndBrandCode(HotelCode.getData(), BrandCode.getData())[0] >

These things make it impossible to use the templates as-is in your project (and visa-versa), so this implementation would only provide the full FTL support, and data through tdd (json) files.

[ThaNarie]

Currently, this is the best I could do (feature/ftl): d86597b

In the brach, use the following new commands:

• yarn compile:ftl - to do a ftl template build (before that, do a normal yarn build to get the assets there)
• yarn dev:ftl - to do standalone development with webpack assets and ftl templates

It uses a similar setup as in the amp feature branch. Instead of doing everything with webpack, both the webpack compiler (for js/css) and a separate watcher (to trigger ftl compilation) are started from the build script.

Hot reloading doesn't work yet, but CSS updates do a behind-the scene refresh, and others will still reload the page within a second, so you get the same speed and effortless development environment.

The FTL pages are rendered with the exact same setup as the handlebars templates (in build mode), and use the exact same data (the page yaml with imports to blocks, etc). They are outputted in the same folder als the normal HTMLs, but with the -ftl.html postfix.

Any shared data/utils/etc can be included in the app.ftl.

I had to use the following freemarker constructs to get the setup working nicely:

Block rendering, with assign alias for easier data access:

Assign:

muban/src/app/component/layout/app/app.ftl

Lines 11 to 12 in d86597b

	<#assign data = block.data>
	<#include "/block/${block.name}/${block.name}.ftl">

Use:

muban/src/app/component/block/paragraph/paragraph.ftl

Line 5 in d86597b

<h2>${data.title}</h2>

Turn on auto-escaping in each HTML file, and use no_esc for raw HTML output:

Turn on:

muban/src/app/component/block/paragraph/paragraph.ftl

Line 1 in d86597b

<#ftl output_format="HTML">

Raw:

muban/src/app/component/block/paragraph/paragraph.ftl

Line 7 in d86597b

<p>${data.content?no_esc}</p>

Make macros for partials to pass information as props:

Macro

muban/src/app/component/general/button/button.ftl

Lines 1 to 5 in d86597b

	<#ftl output_format="HTML">
	<#macro button text>
	<button data-component="button">${text}</button>
	</#macro>

Import:

muban/src/app/component/block/paragraph/paragraph.ftl

Line 2 in d86597b

<#include "/general/button/button.ftl">

Use:

muban/src/app/component/block/paragraph/paragraph.ftl

Line 12 in d86597b

<@button text="${data.ctaReadMore}"/>