SelectedValueComparator is expensive when a DomainClassConverter is used

[sundermann]

Thymeleaf uses SelectedValueComparator from Spring to determine which option tags should be selected. Unfortunately, the algorithm used there is quite aggressive leading to many checks triggering spring's converter service eventually. When a DomainClassConverter is connected then every option tag will result in a database lookup for the option's value. I filed and issue at spring but it seems that this is more an thymeleaf related issue. The spring ticket and a sample can be found at https://jira.spring.io/browse/SPR-12472

[danielfernandez]

Thanks. I've read the Spring JIRA ticket and I think I understand (more or less) the problem.

Thymeleaf's integration with Spring tries to mirror (more or less exactly) what the Spring JSP tag libraries do, so that users don't suffer any unpleasant surprises when they (hopefully) migrate their applications from JSP to thymeleaf.

Thymeleaf's th:field support for <select> and <option> calls SelectedValueComparator.isSelected() because Spring's OptionTag does that same thing. See https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/tags/form/OptionTag.java#L237-L239

So exploring new ways of evaluating whether an <option> tag should be selected or not is fine, but I would feel much more comfortable if such change was done in Thymeleaf and also on the Spring JSP tag libraries, so that we don't end up showing two different behaviours for the same thing.

I'll add a comment in that Spring JIRA ticket asking for their intentions regarding this.