We now relax the generic bound of D to … extends RepresentationModel<?> as otherwise implementation code of, for example, toModel(…) has to produce a concrete representation model and cannot be typed to return RepresentationModel<?>.
Introduced UriMapping to contain the original request mapping used on a controller method as well as a MappingVariables instance that captures all used variables of those mappings. These mappings and variables are not following URI template semantics but rather PathPattern. One example of this playing into the processing is the path segment capture syntax {*…}. This is roughly equivalent to URI template's composite path syntax {/…*}, which however looks different (as the leading slash is contained in the variable expression).
While the handling of those has been added in the commit before, we now introduce the proper abstractions that cause a couple of internal deprecations and binary-incompatible changes and we only want to impose them on implementors upgrading to 2.0. Also, this allows simplifying WebHandler which has accumulated quite a bit of logic already.
We now properly handle path segment capture variables in URI mappings. Values handed into the dummy method invocations are expanded properly and a given null results in the composite segment template variable {/…*} being rendered to advertise the ability to add further segments.
Slightly more compact default regex pattern. Untangle defaulting condition in PropertyMetdata.getPattern(). Extract test cases into dedicated methods. Couple of Javadoc fixes. Java-9-based polishing by using Optional.or(…) in JSR 303 PropertyMetadata implementation.
The presence of @NonBlank on a representation model's property now causes it to be considered required. It will also cause a default pattern exposed that allows clients to validate input values.
Fixes#1757.
Upgrade to Java 17 and Spring Framework 6. Switch to JakartaEE 9 version of the Servlet API. Drop support for Joda Time.
Configure Kotlin plugin to target JDK 1.8 as it doesn't support 17, yet.
As per the discussion in mamund/hal-forms#88, the list of property types in HAL FORMS is not exhaustive. This means we cannot align them with HTML input types and even more so not drop anything not an HTML input type.
This is now implemented by switching to generic Strings in the HAL FORMS property DTO and directly piping the value originally registered on the affordance into it.
When adding a request parameter template variable and the URI part of the template already contains a request parameter we now automatically turn the variable type into request parameter continuation. That apparently got lost in the move to level 4 URI templates in #1583.
The unwrapping nature of EntityModel.getContent() does not work well with value that would result in an empty object being rendered. We now skip the rendering if failing for empty beans is disabled.
We now skip the registration of the default media type if no hypermedia types are activated in the first place. We previously assumed there'd be at least one media type configuration registered.
If a parameter array is given to MethodLinkBuilderFactory.linkTo(…) methods, we now verify its correct length in correspondence to the method given. If no parameters are given at all, we automatically create a parameter value array of the required length.
On JDK 17, trying to proxy Object doesn't work anymore. We now simply return the interceptor that would've been applied to the proxy directly and detect that properly in requests to extract the LastInvocationAware instance.
We now hand the already known property name (from the PropertyDescriptor) to the Property instance we create when inspecting classes for metadata. This avoids ambiguities stemming from the fact that Property assumes Java Bean style properties but Spring's BeanUtils also supporting Java Records style accessors. In special naming contexts like the one used in the test case, this can lead to properties considered "the same" as their accessor methods imply their name is the same.
We now eagerly convert all request parameters and path variables into their String representation using the MVC ConversionService to make sure we can use all formatting metadata available on the parameters.
We now allow explicit definition of a fallback collection element type on CollectionModel to be used in cases of an empty model, so that the RepresentationModelProcessor infrastructure can still reason about the element type and also invoke the processor for empty collection models.
Fixes#1590.
This commit introduces @NonComposite, an annotation to be used with collection or array typed @RequestParam handler method parameters. Using the annotation causes the rendering of request parameters to use the non-composite way of rendering URI template values (param=value1,value2) rather than the default, composite flavor of param=value1¶m=value2.
A bit of polish in TemplateVariable, which now also exposes a prepareAndEncode(Object) method that renders a given value according to the rules defined in the URI template spec for the particular variable type and state (composite VS. non-composite).
We now route calls to WebMvcLinkBuilder.linkTo(Method, Object[]) through the same infrastructure that linkTo(…) calls with a dummy method invocation are routed through. We construct a fake LastInvocationAware pointing to the given Method and parameters.
