Repository files navigation

This extension exports templates from thesource/_patterns/03-templatesdirectory to the backend, similar to the way thatfp template does. However,the output will compile all included partials. Furthermore, this extensionobviates the need to declare a translation for each tag.

This should prove to be a simpler alternative to Fepper core'sfp templatetask, but it is probably not appropriate for many CMSs (like Drupal andWordPress) for whichfp template was originally designed.

Instead, this extension is more suitable for Express-like applications, whereany number of routes can be assigned a unique template for rendering HTML.Unlike Drupal and WordPress, instead of the backend trying to determine whichpartial goes where, the inclusion of partials, as appropriate per route, wouldbe prototyped in Fepper. Runningfp tpl-compile would then compile a singletemplate per route.

cd extendnpm install --save-dev fp-tpl-compile

This does the compilation as described in the first paragraph. You will stillnormally need to translate from Fepper's Mustache syntax(Feplet)to the backend's template language.fp tpl-compile leverages normal Fepletrendering, but targets the tag delimiters instead of the entire tag. You arefree to use any alternate delimiter, but we recommend ERB notation, asexemplified in theMustache docs.Wrap them in triple curly braces and use them as opening and closing delimiters.Use these wrapped delimiters to surround tags destined for the backend. In theexample of ERB alternate delimiters and regular{{ and}} delimiters for thebackend, the.json file specific to the Fepper template must declare<% and%> keys and have their values be{{ and}} respectively. Insource/_data/_data.json file, their values should be<!-- and--> so theycan be ignored by humans viewing the UI.

Each template that is to be compiled requires a.json file with alternate andbackend delimiter declarations. While this may appear to be unnecessarilyrepetitive, it leverages normal Fepper rendering, instead of hacking around it.It also avoids the chaos that global configurations for opening and closingdelimiters for alternate and backend tags would instill. (Yes, that's fourconfigurations. Yes, their keys would be long and/or unguessable.)

Thetpl_compile_dir andtpl_compile_ext preferences need to be configured inpref.yml or the template's.yml file. In this way,fp tpl-compile willknow where to write, and what extension to use.

fp tpl-encode:hbs works in the reverse direction. It encodes backend templatesfor use as Fepper templates, which can in turn, be compiled back to the backend.Assuming the backend template is fully fleshed out, copy it tosource/patterns/03-templates. Do not change its name. Then, run the commandwith the extension used by the backend. The copied backend template insource/patterns/03-templates will be replaced by a.mustache file,accompanied by a.json file.

The.json file will declare ERB notation for alternate delimiters. The encoderwill also add the"<%": "<!--" and"%>": "-->" key:value pairs tosource/_data/_data.json if they aren't there already.

One gotcha to be aware of is that underscore-prefixed hidden files must not havea corresponding.json file. Underscore-prefixed.json files will getcompiled intosource/_data/data.json, possibly overwriting values for<% and%>.

fp tpl-encode:hbs encodes any backend language with tags delimited by{{ and}}.

The output HTML will be formatted byjs-beautify.To override the default configurations, modify the.jsbeautifyrc file at theroot of Fepper.

<h1>{{{<%}}}title{{{%>}}}</h1>{{>00-elements/paragraph}}<footer>{{{<%}}}{footer}{{{%>}}}</footer>

{  "<%": "{{",  "%>": "}}"}

tpl_compile_dir:docroot/templatestpl_compile_ext:.hbs

<p>{{{<%}}}backend_content{{{%>}}}{{placeholder_content}}</p>

{  "placeholder_content": "Lorem ipsum",}

"<%": "<!--","%>": "-->"

<h1>{{title}}</h1><p>{{backend_content}}</p><footer>{{{footer}}}</footer>