Unable to handle model properties that contain dots (`.`)

[checketts]

With Spring validation, when a form entry has an error Spring adds a BindingResult to the model with the key similar to org.springframework.validation.BindingResult.myEntry. However there isn't a way to reference the model entry via a @param

@param org.springframework.validation.BindingResult.myEntry: org.springframework.validation.BeanPropertyBindingResult

Since there are dots in the variable name that isn't allowed.

Would a PR for the Spring integration that changes the dots for underscores be welcome?

I'm looking to see if there are other options as well...

[casid]

Hi @checketts,

thanks for reporting and, ooof, this is wild. I'm not a Spring user, but modifying Spring keys to match jte parameter name syntax is asking for trouble. For instance, once Spring starts having keys with underscores that might collide with the hacked keys.

I'm not sure, but maybe there could be other ways to access those things into the jte templates?

Input from real Spring - jte users would be very welcome here :-)

[checketts]

The way I've worked around it in my code is to create a ValidationHelper that looks up the validation results. I'll iterate on it a few times, then we could look into adding that in the Spring library and make it configurable.

For JTE, when populating a @param would it be worth supporting handling the periods in model keys? Like mapping those to params with underscores?

For example (in a kte file):

@param org_springframework_validation_BindingResult_myEntry: org.springframework.validation.BeanPropertyBindingResult

Then if there is a key with underscores that would match, it would be used first, and if not, then check for a key with periods?

[casid]

No, I would rather not introduce this kind of magic to jte.

It will add a performance overhead for every template invocation through maps. It also obfuscates constants (e.g. in your example a project wide search will not find org.springframework.validation.BindingResult.myEntry in jte templates).

Adding a utility method to the spring lib sounds like a much better API for this problem.