ResolvablePattern problem. Why not allow users to create their own Pattern objects?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

ResolvablePattern problem. Why not allow users to create their own Pattern objects?

Rich MacDonald
I am matching the actual template strings and not filenames, because the file has already been read by the time the code gets to Thymeleaf.

The templates are stored in a file.

So the first resolver is a FileTemplateResolver because it needs to match the <filename::templatename>.

The second resolver is just a StringTemplateResolver that matches everything.

Now many of the strings will not have a template reference, so they can be skipped without incurring the parsing cost.

So I want the StringTemplateResolver to match a thymeleaf pattern. If it finds a " th:", then it knows it must parse the string.

This is failing because Thymeleaf pre-processes the patternStr via PatternUtils.strPatternToPattern(). And it includes the "^$" pattern. So " th:" becomes "^ th:$".

Except my strings contain line breaks. So I need to append the multiline modifier. But I cannot, because it needs to go after the "S".

Well I can get around this with the "space/no-space" trick:

(https://stackoverflow.com/questions/8303488/regex-to-match-any-character-including-new-lines)

So the patternStr becomes "[\S\s]*th:[\S\s]*". PatternUtils turns this into "^\[\S\s\](?:.*?)th:\[\S\s\](?:.*?)$".

This isn't going to match anything.

I'm going to have to solve this with a simple myTemplateStr.contains(" th:") check before calling Thymeleaf. (And it will be faster than any pattern matching algorithm.)

But imho the framework would be improved by adding an AbstractTemplateResolver.setResolvablePatterns(Set<Pattern> setOfPatterns) method.