Support customizing additional HAL-FORMS properties

Now that we’ve got support for prompt thanks to #979, it would be nice to add support for the remaining “standard” HAL-Forms properties. I did notice that it adds the prompt everywhere using the name, rather than only adding it when defined. According to the spec, if the prompt is missing, clients MAY act as if it was set to the value of name. #979 kind of short-circuits that.

Some thoughts:

• readOnly - could use absence of setter to auto-set
• regex, required - #619 suggests using JSR-303, which seems like a clear and elegant solution
• templated, value - honestly, I’m not certain at the moment what these would be used for, so I don’t feel qualified to make any suggestions

It seems easy enough to simply add the rest from a resource bundle, and I briefly considered creating a PR until I remembered the corporate proxy I’m stuck behind that blocks the git protocol, which, in this case, is probably a good thing since I think the solutions above are much more elegant and better for long-term maintenance of the consuming codebase. It might still be beneficial to allow overriding through resources, but I don’t know how that fits into the Spring philosophy (I’ve only just picked up Java again after a 15 year absence and Spring has changed just a little bit since then).

[odrotbohm]

The reason I made this distinction in the first place is that in domain types (as opposed to DTOs), JSR-303 is often used to “implement” domain constraints when a value type would’ve been the better alternative:

@Email
String emailAddress;

While this is perfectly fine in a DTO, it will probably have to be able to capture invalid values as well to produce proper validation messages, in the context of a domain object as nobody using the emailAddress property will be able to know whether it actually contains an email address or an arbitrary string. I.e. in a domain objects you’d definitely prepare:

EmailAddress emailAddress

I went ahead and added the support for JSR-303s @NotNull to mark required properties as well as @Pattern to define regular expressions. The later can also be used on types which will in turn render properties of those with the registered pattern. Also, HalFormsConfiguration now has a method to register patterns by type globally. See more on that in the updated reference documentation.

Please give the current snapshots a try. We still have one week until RC1 and I’m happy to tweak things further.

[colin-young]

Looks good. Working as expected again.

One minor error in the docs: in Example 35 it shows Employee.firstName=Firstname but I think that should be Employee.firstName._prompt=Firstname. I created #1028 to fix it.