java - Thymeleaf, fragments and default parameters

Question

I have created fragments.html file. It contains the following fragment:

<div th:fragment="my_fragment(content)">
    <p th:text="${content}"></p>
</div>

I put the above fragment into my view file:

<div th:replace="fragments :: my_fragment('test')"></div>

Now, I want to pass two parameters to my_fragment, but I must ensure backward compatibility.

I tried to solve the problem as follows:

<div th:fragment="my_fragment(content, defaultParameter='default value')">
    <p th:text="${content}"></p>
</div>

Unfortunelly, the above solution generated error:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateProcessingException: Cannot resolve fragment. Signature "my_fragment (content,defaultParameter='default value')" declares 2 parameters, but fragment selection specifies 1 parameters. Fragment selection does not correctly match.

Any idea?

question from:https://stackoverflow.com/questions/22093149/thymeleaf-fragments-and-default-parameters

Answer 1

Thymeleaf allows a signature of a fragment without explicit parameters like this:

<div th:fragment="my_fragment">
    <p th:text="${content}"></p>
    <p th:text="${defaultParameter}"></p>
</div>

To call this fragment and pass content and defaultParameter you may call the fragment as follows:

<!-- both parameters not specified -->
<div th:replace="fragments :: my_fragment"></div>
<!-- only content parameter specified -->
<div th:replace="fragments :: my_fragment(content='a')"></div>
<!-- both parameters specified -->
<div th:replace="fragments :: my_fragment(content='a', defaultParameter='b')"></div>

But the below will not work:

<div th:replace="fragments :: my_fragment('a', 'b')"></div>

And the message is self-explonatory:

 Signature "my_fragment" declares no parameters, but fragment selection did specify parameters in a synthetic manner (without names), which is not correct due to the fact parameters cannot be assigned names unless signature specifies these names. 

So in case you want to maintain backward compatibility, you should use named parameters while calling a fragment and do not specify parameters in a signature of a fragment.