he rationale for using template engines to render views in Java web development is generally two-fold:
- Templates can be created and maintained by HTML coders.
- Templates are easy for HTML coders to read, as they are based on HTML formatting.
In my experience, both arguments are flawed. The first one rarely happens, and the second holds true initially but becomes seriously compromised as soon as any presentation logic is introduced. Groovy builders, a literate solution for bringing view rendering back into your code, provide a better alternative to the template engine.
This article explains the issues inherent in using template engines, and then shows how to use Groovy builders for view rendering.
Template Engine Issues
When using template engines for view rendering, you will encounter two main issues that make templates less than ideal:
- Limited design options
Templates are hard to test. Imagine you are implementing some presentation logic to highlight alternate rows in a table (this will serve as the view-rendering example in upcoming sections). Depending on the template technology you're using, you will face different costly and time-consuming requirements. With JSP, you would need to take one of two approaches:
- Out-of-container compilation (assuming your servlet container allows it)
- Within-the-container compilation (when your servlet container doesn't allow out-of-container compilation)
For the first approach, you must:
- Compile the JSP into a servlet class that can be executed.
- Execute the compiled JSP, providing your data is in the correct scope.
- Parse the output to ensure the correct rows have been given the highlight class.
For the second approach, you must:
- Deploy your application to your servlet container.
- Make sure the container and application is running.
- Use a testing library like HTMLUnit to call your page.
- Check the correct rows have been given the highlight class.
Given the high cost of these options, it is no surprise that presentation logic in JSP is rarely tested.
Testing is a little easier if you use another template language, such as FreeMarker. In that case, you will at least be testing the page in the same environment as it is executed. However, you still have to render the view template file and parse the output to verify that the rows had the correct classes applied.
Limited Design Options
When using templates for view rendering, you are limited to your framework's implementation when you decide how to make sections of your view reusable. With JSP, you must use tags to create view components. With FreeMarker, you are able to implement macros. While SiteMesh uses the decorator pattern. If you were able to use code to implement the view, you would have the full power of object-oriented techniques and be able to use whichever design pattern you wish.
Both the testing and design options problems stem from the fact that template solutions are external rather than internal domain-specific languages (DSLs). As such, templates are developed outside of the scope of your programming language and therefore are likely to lack flexibility.