Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>From my experience, Freemarker really only has two classes of errors when trying to render a template (Ignoring configuration):</p> <ul> <li>Simple syntax errors at the template level</li> <li>Assumptions about the model passed in at the Java level are incorrect</li> </ul> <p>Although linting tools typically do find errors in code, a lint tool does not replace the need for basic testing, which is a far better solution for what you're experiencing here since you are seeing exceptions in production code.</p> <p>For better or for worse, Freemarker's assumptions about who is working with the data and who is working with the markup are different people with different skillsets. Assuming this is the case (and you have Java engineering resources to spare), you have two ways of approaching this problem from a test process point of view (Although to be truly rigorous, you want both).</p> <h2>Frontend Testing</h2> <p>At my previous job, we used this approach by itself. Basically, the front-end engineers would hack templates on a special web frontend where the edited templates were directly on the configuration path containing two listings:</p> <ul> <li>The template to render</li> <li>Versions of the data model to render</li> </ul> <p>The 'versions' were essentially a two-tiered set of hardcoded Java objects, where Tier 1 was consistent across all of templates, and Tier 2 was template-specific variations. Because most of our emails were account-level notifications, we got a lot of mileage and reuse out of just having the global data model, and we rarely had to dig into the small stuff.</p> <p><strong>Benefits</strong></p> <ul> <li>The Frontend engineers never need to touch Java, so you can use your HTML/CSS mavens for their intended purpose if that's what you have on your team</li> <li>The Backend engineers can recycle a lot of stuff depending on the templates and their construction</li> <li>Loosely enforces a uniformity of data model variable names when referring to frequently used values such as "account" (The Frontend engineers would get annoyed when values they expected weren't there because a different backend engineer named something 'incorrectly')</li> </ul> <p><strong>Not So Good</strong></p> <ul> <li>This basically is manual testing, and at some point will fail to catch an error</li> </ul> <h2>Backend Testing</h2> <p>The other alternative is form unit tests for each template as they are created. Because the exceptions in Freemarker all happen at compile time, you will only need to do the following (After you do initial setup):</p> <pre><code>Template temp = cfg.getTemplate("myTestedTemplate.ftl"); temp.process(myTestDataModel, myIgnoredOutput); // No exceptions -&gt; OK for us </code></pre> <p>Note that you don't care about the result in this case, you just need it to compile. This is important because you can easily get bogged down in debugging compiled output in Java and not solve the current problem. As before, you will also want to do the same two-tiers of unit tests here in all likelihood:</p> <ul> <li>Smoke test all templates with some generic model (Getting each template can likely be done programmatically)</li> <li>Test individual templates with the variations in data model that you expect (Missing settings, incomplete fields, etc.)</li> </ul> <p><strong>Benefits</strong></p> <ul> <li>Part of the build/deploy process, so you eliminate human error in the templates</li> <li>Depending on how you are using Freemarker, this can also verify the data models are being generated correctly by other processes if you aren't doing so already</li> </ul> <p><strong>Not-So-Good</strong></p> <ul> <li>Frontend Engineers will need to read stack traces to find out what failed</li> <li>Development using this method ends up getting tied to your build process, which is nowhere near as fast as reloading a page</li> </ul> <p>If you have the time to do both, I would recommend work on using unit tests to handle the edge cases and other concerns that you find as they pop up, then the web frontend for development so that developing the page doesn't require a recompile. The ability to version frontend is extremely beneficial, but the goal is to prevent errors in production to the build process first. Launch, then optimize and all.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload