The HTML Template Language HTL (formerly called Sightly) is a modern replacement for JSP that provides the dynamic behaviour by using HTML5 like data attributes and using HTML elements as block statements, and provides enhanced security against XSS by tightly integrating with HTML syntax and automatically escaping data properly.

The ComposumModelUseProvider extends the HTL Java Use-Api such that an object can be created not only from the request and the rendered resource, but also if it can be created from the BeanContext with BeanContext.adaptTo, which supports the creation of both SlingBeans and Pages Models with or without Sling-Models. Thus, to create a Composum Model is as easy as e.g.

To enable communication between templates we implement a kind of pagecontext for HTL by putting a map into a request attribute. There are separate maps for each script name (that is, the resource of the script) plus the rendered resource path. The emulated page context can be accessed from the Composum tags, or via the AttributesUseProvider (see below).

The AttributesUseProvider allows reading request- or session-attributes or the EmulatedPageContext with a data-sly-use statement such that the IDE knows the specific class and can provide code-completion etc. This use provider is activated whenever the fromScope parameter is present. Usage example (reads the search result from a request attribute searchresult):

Possible scopes (case insensitive) are bindings for the script bindings, page for the emulated page context, and request and session.

It is also possible to explicitly pass an explicit value with parameter value to effect a IDE-visible typecast. (The given value is not changed).

As an example for the use of HTL we reimplemented the search component in a small test site within cpm-platform-htl, so it's easy to compare the JSP to the HTL approach.

The component is located at /apps/composum/prototype/platform/htl/components/search and contains two subcomponents.

• the field component demonstrates the use of the HTL emulation of the composum tags startElement and startForm within the HTL file.
• the result component has an alternative approach: it puts the composum tags in their normal form into a JSP wrapper result.jsp (see below) which then includes a pure HTL script result.htl.html that does the HTML markup. This works well when the composum tags can easily be wrapped around the markup, as with the cpp:element tag here, and combines the clarity and IDE-support of JSP tags with the possibility to do the rendering code mainly in HTL. The attributes generated by the cpp:element tag are transported as request attributes and are retrieved in the HTL with data-sly-use statements with fromScope="request" as discussed above.
  

It is also possible to implement dialogs and other parts of the component which are heavily laden with Composum tags in HTL, too. That does, however, not seem very advisable, since that reduces readability - please compare dialog.jsp with the HTLized equivalent dialog.html.

• A data-sly-call on an element throws away the content of the element. Thus, it is not possible to modify, conditionally throw away, or repeat the content of the element, or easily surround some content with a computed number of elements. Partial solution: split up the tags with content into a start and an end template. Problem: functionality that concerns the content of a tag cannot be implemented, and no variables for the content of the tag can be set. (Possible extension of HTL: the content of the data-sly-call element could be delivered to the template e.g. as a RenderUnit as a binding variable, which could be rendered once or several times via a new mechanism.)
• There seems no way to define something like functions as in a tag library. (Idea: Use-Provider that calls a static function and delivers the result? (no IDE support.) Special class for each taglib function with constructor parameters corresponding to the arguments of the taglib function?)
• In a template the parameters cannot be documented. Thus, it is not possible to see documentation within the IDE.
• It is not possible to modify the global variables from a template. Thus, it its not possible to emulate a tag like cpp:defineObjects that defines several objects at once - the closest you can do is to create a model class that has several attributes with the objects to define. (Mostly OK; perhaps HTL could be extended that a template could also define some models, not only templates.).
• data-sly-use for template libraries etc. does not use the resource search path (/apps, /libs, ...)
• To output an attribute of type URI one needs to insert .toString - URI are silently swallowed.