Thymeleaf, fragments and default parameters

user3364391 picture user3364391 · Feb 28, 2014 · Viewed 36.5k times · Source

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?

Answer

Rafal Borowiec picture Rafal Borowiec · Mar 2, 2014

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.