This feature enables the creation of HTML fragments that can be embedded in other HTML documents, such as tables, without requiring a complete HTML structure.

It adds Span as a valid HtmlPage root element and includes root builder extensions for div, tr, and span, along with their corresponding tests.

HtmlFlow is now free of any Kotlin dependency, and only htmlflow-kotlin requires the Kotlin standard library.

In the new xsd2poet-java, the ElementVisitor no longer includes visitSuspending. The visitSuspending method is now exclusively part of the Kotlin version.

This release also resolves Issue 136.

As a result, the core Java HtmlFlow module no longer depends on the Kotlin coroutines library or jsoup (which is now only required by the reverse-engineering tool Flowifier, moved to its own module).

HtmlFlow is now organized into four distinct modules:

• htmlflow-core: The main library (the htmlflow artifact) containing the Java API.
• flowifier: A reverse-engineering tool for translating HTML documents into equivalent HtmlFlow view definitions.
• htmlflow-kotlin: The idiomatic Kotlin API (which depends on htmlflow-core).
• htmlflow-view-loader: A reflective inspector for HtmlFlow view definitions. It loads Kotlin functions of type T -> String that return rendered HTML.

Additionally, an mfe() builder has been added to dynamically load HTML fragments, supporting both SSR and CSR approaches within HtmlFlow view definitions.

It also introduces ViewFactory.Builder, allowing configuration of HtmlView parameters, such as isIndented, threadSafe and preEncoding.

Finally, it adds a new type of Hot view that recalculates all HTML—including static HTML blocks— on each rendering, which is useful for http4k integration with hot-reload support.

1. Unified API Generators: Combines two previously separate API generators—one for Java and another for idiomatic Kotlin builders using function literals with receivers—into a single unified infrastructure.

2. Simplified Manual Integration: Streamlines the process of merging manually written builders (e.g., of(), dynamic(), async(), suspending(), etc.) with automatically generated HTML builders.

Initially, when we introduced an alternative Kotlin API alongside the existing Java API, the automatic Kotlin generation mechanism was not integrated into the existing HtmlApiFaster infrastructure. Instead, as an experimental approach, we integrated it directly within the HtmlFlow module using KotlinPoet to generate Kotlin source code. This was a departure from the previous approach, which relied on ASM (a Java bytecode manipulation library) to generate the element classes that make up the HtmlFlow Java API.

Additionally, extending the autogenerated Element base interface to include new dynamic features was cumbersome. The legacy process required manually merging custom additions after running the automatic generation.

With the introduction of the new xsd2poet dependency, which replaces the legacy XsdAsmFaster and HtmlApiFaster, we now generate source code instead of bytecode. Furthermore, we have refactored the backbone of the org.xmlet.htmlapifaster API to be maintained as source code rather than dynamically generated classes.

This new approach significantly simplifies the maintenance and enhancement of HtmlFlow’s custom features.

You can write HTML structures in a natural, hierarchical way using nested lambdas, or use method chaining for concise simple sequences:

body {
    div {
        p { 
            text("Hello") 
        }
    }
}

body.div.p.text("Hello").l.l.l

Both approaches are available depending on your preference - nested lambdas for readability with complex structures, or method chaining for concise simple sequences.

• Added Kotlin extensions, such as the .l property, which can be used to close tags in Kotlin instead of .__().
• Introduced a new .suspending() builder to support the use of continuations in Kotlin, allowing suspending functions to use await.
• Resolved Issue 105 by integrating new attributes in globalEventAttributes, included with the release of HtmlApiFaster 1.0.15.
• Added new unit tests verifying multi-threaded scenarios.
• Updated the documentation to detail setIndentation() usage and the correct application of threadSafe().

• Resolved Issue 103. Using .text() interleaved with attributes is no longer supported and will now throw an exception.
• Resolved Issue 104. Disabling indentation incorrectly removed newlines inside text and script blocks. This has been corrected.
• Enhanced the documentation with additional examples of data binding, conditionals (if/else), and loops.
• HtmlView is now strongly typed with the type M corresponding to the model.

• HTML boolean attributes are no longer emitted when assigned a false value.
• Added new types for the Script tag, including module and importmap.
• HtmlViewAsync now supports thread-unsafe views, allowing sequential execution even if asynchronous relative to the data model.

• DynamicHtml and StaticHtml are replaced by HtmlView and HtmlDoc, respectively. Both inherit from the new HtmlPage type.
• The factory methods DynamicHtml.view() and StaticHtml.view() have been moved to the HtmlFlow class, becoming HtmlFlow.view() and HtmlFlow.doc().
• The HtmlWriter interface, which previously defined standard methods (write and render) for all HTML pages, has been removed. With the dynamic nature of HtmlView (formerly DynamicHtml), render(model) and write(model) now require a model argument. These methods are not applicable to HtmlDoc (formerly StaticHtml), leading to the removal of HtmlWriter. The base class HtmlPage no longer defines write or render methods.
• HtmlPage, HtmlView, and HtmlDoc are no longer parameterized with the model type. The model is now parameterized only when using the builder <M> dynamic(BiConsumer<E, M> consumer), where E is the parent HTML element and M is the model type.
• The model object is now passed directly as a parameter to the consumer of a dynamic block (e.g., calling .dynamic((elem, model) -> ...)), eliminating the need for closures to capture the model object.

For example, the dynamic blocks approach has been simplified:

public void template(DynamicHtml<Pet> view, Pet pet) {
    view.div().h2().dynamic(h2 -> pet.getName()).....
    ...

public void template(HtmlPage view) {
    view.div().h2().<Pet>dynamic((h2, pet) -> pet.getName()).....
    ...

• Partials are now the only place where closures can capture a model object of a different type than the enclosing template. When doing so, you must use a dynamic() block to prevent the partial from being stored as static HTML and ensure it renders whenever called with a model. If the partial uses the same model as its container, avoid the closure and instead use the model provided to the dynamic(cons) builder.
• The addPartial() builder has been removed. A partial is now simply a consumer function of an HTML element (Consumer<E extends Element>). You can combine partials using higher-order function composition. The element serves as the parent HTML where HtmlFlow continues to emit code. Additional arguments corresponding to context models can also be passed to partial views.

You can find this sample in the unit tests at htmlflow.test.views.HtmlCustomElements.

Invoking .custom("alert-info") returns an instance of the new CustomElement class, which inherits from the existing Div class. As a result, the returned instance has most HTML features available.

Example usage:

StaticHtml
  .view()
      .html()
          .head()
              .script()
                  .attrSrc("alert.js")
                  .attrDefer(true)
              .__()
          .__()
          .body()
              .div()
                  .attrClass("container")
                  .p().text("Testing custom elements!").__()
                  .custom("alert-info")
                      .addAttr("title", "Information")
                      .addAttr("message", "This is a message for a custom element")
                      .addAttr("kind", "success")
                      .ul()
                          .li().text("For any reason we could even include other elements.").__()
                      .__()
                  .__()
              .__()
          .__()
      .__();

This feature introduces a couple of new internal methods, including newby() in HtmlVisitor, which creates a new instance of the same type while preserving indentation.

Resolves Pull Request 75.

Updated the JUnit release to address a reported vulnerability. For details, see Pull Request 68.

The project defines templates as first-class functions, leveraging Java language features while removing auxiliary Spring infrastructure components like ModelAndView and ViewResolver. Consequently, validations regarding these mechanics have been removed from the unit tests.

This change improves compatibility with applications such as spring-comparing-template-engines that do not support higher Java versions.

Resolves Issue 43.

• Upgraded to Java 11.
• Upgraded to HtmlApiFasterApi version 1.7.
• Added a HtmlPartials class in the unit tests project with sample use cases.
• Disabled the use of chained calls to dynamic() to prevent unexpected cache behavior.
• Added support to disable HTML output indentation via the setIndented(boolean) setter on HtmlView and the corresponding property in HtmlVisitorCache.
• Fixed support for pre elements in body as described in issue #46, including the ability to disable pretty print HTML indentation.