What is wrong with using stringly typed templates?

Stringly typed templates use String literals to access data structures. Top-level data structures are typically passed from Java code to the template processor as key-value pairs in a Map.

The first problem is run-time errors caused by human error. Developers can introduce bugs by:

• mismatched identifiers in the Java code and Template mark-up for accessing top-level items
• mismatches between Java method names used in the data structures and in the templates
• template syntax errors

These kinds of errors can only be found at run-time. Hopefully this happens during automated or manual testing rather than in production. The strong typing used in bLight templates eliminates this risk by having the Java compiler pick up these kinds of errors. Invalid templates will not compile, and therefore cannot be deployed.

The second problem with Stringly typed templates is decreased developer productivity due to inadequate tool support. bLight templates offer the following advantages in Modern IDEs:

• Java context-sensitive assistance & text auto-completion
• Automated refactoring of templates when classes/methods are renamed.
• Easy access to data structure Javadoc

What output formats are supported?

bLight supports generation of any text output format, such as plain text, HTML, XML, email, etc. It is simple to extend AbstractTemplate to add output-specific productivity methods.

Can I write re-usable template components?

Yes - see AbstractTemplate.include(AbstractTemplate).

How far you should go depends on your personal preference. For example, developers coming from a web-development background may find it easier to visualise page structure if it is written in HTML rather than a collection of method calls. Common site header/footer templates are probably a good start.

Does bLight support internationalisation (i18n)?

bLight does not directly support i18n, but the bLight AbstractTemplate is designed to be sub-classed to add application-specific utility methods. For example, create an i18n utility method and replace:
   /*<h1>Welcome</h1>*/
with:
   /*<h1>*/i18n(AppMessages.WELCOME);/*</h1>*/.

Does bLight break MVC by placing too much logic inside the view?

Not necessarily, but it is easier to fall into this trap than in other templating languages. Other templating languages do still allow template mark-up to call Java code (other than the model beans), but developers usually have to go out of their way to enable this. Peer reviews are recommended for junior developers to encourage good development practices.