The Ultimate Guide to AD0-E303 Adobe Campaign Classic Architect

The Ultimate Guide to AD0-E303 Adobe Campaign Classic Architect AD0-E303 Adobe Campaign Classic Architect Certification Exam Credential. The HTML Template Language (HTL) supported by Adobe Experience Manager (AEM) is the preferred and recommended server-side template system for HTML in AEM. It takes the place of JSP (JavaServer Pages) as used in previous versions of AEM. It is recommended for new AEM projects to use the HTML Template Language, as it offers multiple benefits compared to JSP. For existing projects though, a migration only makes sense if it is estimated to be less effort than maintaining the existing JSPs for the coming years.

But moving to HTL is not necessarily an all-or-nothing choice, because components written in HTL are compatible with components written in JSP or ESP. Meaning that existing projects can without a problem use HTL for new components, while keeping JSP for existing components.

Even within the same component, HTL files can be used alongside JSPs and ESPs. Following example shows on line 1 how to include an HTL file from a JSP file, and on line 2 how a JSP file can be included from an HTL file.

Frequently Asked Questions Before getting started with the HTML Template Language, let’s start with answering upfront some questions related to the JSP vs HTL topic.

Does HTL have any limitations that JSP doesn’t? - HTL doesn’t really have limitations compared to JSP in the sense that what can be done with JSP should also be achievable with HTL. However, HTL is by design stricter than JSP in several aspects, and what can be achieved all in a single JSP file, might need to be separated into a Java class or a JavaScript file to be achievable in HTL. But this is generally desired to ensure a good separation of concerns between the logic and the markup.

Does HTL support JSP Tag Libraries? - No, but as shown in the Loading Client Libraries section, the template & call statements offer a similar pattern.

Can the HTL features be extended on an AEM project? - No, they cannot. HTL has powerful extension mechanisms for reuse of logic - the Use-API - and of markup (the template & call statements), which can be used to modularize the code of projects.

What are the main benefits of HTL over JSP? - Security and project efficiency are the main benefits, which are detailed on the Overview.

Will JSP eventually go away? - At the current date, there are no plans along these lines.

Fundamental Concepts of HTL The HTML Template Language uses an expression language to insert pieces of content into the rendered markup, and HTML5 data attributes to define statements over blocks of markup (like conditions or iterations). As HTL gets compiled into Java Servlets, the expressions and the HTL data attributes are both evaluated entirely server-side, and nothing remains visible in the resulting HTML.

Blocks and Expressions Here’s a first example, which could be contained as is in a template.html file: The two pages linked above provide the detailed list of features available for syntax.

The SLY Element A central concept of HTL is to offer the possibility of reusing existing HTML elements to define block statements, which avoids the need of inserting additional delimiters to define where the statement starts and ends. This unobtrusive annotation of the markup to transform a static HTML into a functioning dynamic template offers the benefit of not breaking the validity of the HTML code, and therefore to still properly display, even as static files.

However, sometimes there might not be an existing element at the exact location where a block statement has to be inserted. For such cases, it is possible to insert a special SLY element that will be automatically removed from the output, while executing the attached block statements and displaying its content accordingly. will output something like following HTML, but only if there are both, a jcr:title and a jcr:description property defined, and if neither of them are empty: One thing to keep in mind is to only use the SLY element when no existing element could have been annotated with the block statement, because SLY elements deter the value offered by the language to not alter the static HTML when making it dynamic.

For example, if the previous example would have been wrapped already inside a DIV element, then the added SLY element would be abusive: