Shower

When I designed Shower I was working for an ERP vendor. We implemented the web shop. As such a shop is sold many times it needs some flexibility in its look. As we planed to implement customer specific additions by our people, and the ERP system was not written in java I had to avoid any addition complexity. And, to make them feel a little more home, some concepts are oriented on the API of the ERP system.

Technically Shower is a wrapper around XML DOM. As such it's entirely based on XML and the 'compilation' step within the build ensures a certain level of quality. The templates are valid XML files. If they're HTML they look exactly like page rendered by the app. No awkward syntax visible only mock data. It adds a simple API focusing on binding data to document and URLs, replicating sections with variant handling and forcing user rights. To enforce the user permissions there are three operations:

• hide a field or table row including its label
• make a field not editable
• remove all links to a special target from the entire page

To achieve this it has a strong understanding of HTML and uses this for strong automation features. It ensures document validity by escaping and encodes all emitted URLs with response.encodeUrl() and as the response is wrapped (RequestContextPattern) one can add even more functionality.

Compared to JSP I felt very comfortable with this environment even though it had some shortcomings. The necessity to open and close all sections outside the renderers created quite some glue code, and I had much configuration due to servlet usage. The JavaScript support is quite limited. Compared to Snippetory, it's much more bound to HTML, more complex in handling and implementation and missing this repository aspect. It has a much stronger support for automation (i.e. operations on all links...) and, a bit stronger abstraction from the template as it doesn't matter where the output of a field is located on the page. It's a web framework and not just a template engine.