This method is currently used in test cases only and the just introduced ability to rename property makes the method not reliably usable as the way it is named doesn't convey which name is to be used. It currently is the potentially renamed value. Moving to the actual property name as input creates stronger boundaries to assume a type backing the metadata, which we want to avoid.
Handler method parameters annotated with @RequestParam(defaultValue = …) are implicitly not required and thus should still be advertised in the URI templated generated. Previously it was necessary to explicitly set @RequestParam(required = …) to false.
Original pull request: #1511.
Related ticket: #331.
We pulled up the parameter name lookup for request parameters to avoid repeated lookups but unfortunately missed that the lookup will fail e.g. for @RequestParam Map<…> as we now strictly tried to find a request parameter name that doesn't actually exist in this case.
We now also eagerly map the keys for the _embedded map in a HAL response to Strings to make sure they work properly when sorting of map keys is activated for the Jackson ObjectMapper.
@EnableHypermediaSupport(types = {}) was not working anymore as the Comparator implementation working with the selected types rejected an empty list. We now do not reject that anymore to enable applications that solely work with third party media types.
Prior to this commit, the map of links to be rendered would key by LinkRelation. Unfortunately, Jackson requires `Map` keys to implement `Comparable` in case `SerializationFeature.ORDER_MAP_ENTRIES_BY_KEYS` is enabled. We now use the link relation's value as key right aways as Strings are comparable out of the box.
Switched to use Spring's MultiValueMap to avoid having to deal with the value list initialization ourselves.
We now check whether we could really load `@Range`, which is only available in Hibernate Validator. An arrangement in which the Validation API JAR is on the classpath but not Hibernate Validator would let us end up with the relevant instance being `null` and need a check for before being handed into code that requires the type to not be `null`.
Configuring the Link.of(…) factory method as explicit creator method allows us to get rid of the wither chain previously required in HalLinkListDeserializer.
Moved the affordance metadata caching into SpringAffordanceBuilder and separate the caching of the metadata lookup from the assembly of the affordance. The latter is based on the URI resulting from expanding the request mapping with the given value and thus is likely to produce a lot of different values so that they're rather unsuitable as cache key.
That means that we now return fresh Affordance instances for every request which probably causes a tiny hit on performance but still does not need additional metadata lookups. Also, it opens up the door to enrich the affordances with property value providers that would allow us to render affordance fields that refer to a instances property, e.g. to render edit forms.
We now support defining the options element [0] for a HAL-FORMS property by registering a lookup of HalFormsOptions instances on HalFormsConfiguration.
[0] https://rwcbook.github.io/hal-forms/#options-element
Switched from using regular expressions to a simple manual parsing algorithm for the attributes attached to a link. Adapt a couple of broken tests that previously erroneously worked.
This is to make sure the custom converters registered by Spring Data REST, which all extend MJ2HMC, do not get the general customizations added as they otherwise trump the explicit configuration that Spring Data REST sets up.
Switched to manual parsing of template variables as regular expressions can contain { and } characters which makes matching variables using these as delimiters impossible.
Related ticket: #1412.
Changed the configuration of media type specific representation model rendering to rather use the existing MappingJackson2JsonConverter than registering custom HttpMessageConverters ourselves. The same applies to codecs in WebFlux.
Added HypermediaMappingInformationComparator to be able to sort HypermediaMappingInformation instances by their corresponding media type configuration on @EnableHypermediaSupport.
HalConfiguration now exposes a withMediaType(…) that adds custom media types in front of the default of `application/hal+json`. This allows developers to use a project specific media type which is treated like it being HAL in the first place.
We now look up the ConversionService available in the ApplicationContext from Web(Mvc|Flux)LinkBuilder. Some API tweaks to WebHandler to allow the lookup from the current request. The general fallback is now the invocation of …toString() on the parameter value.
Fixes#118, #352, #144, #149.
Got rid of quite a few custom serializers in Jackson2HalFormsModule. We now rely on the HAL setup mostly and register a virtual bean property to render the _templates field. The Jackson component used for that is registered as Spring bean so that we can now use the HAL HandlerInstantiator with the Jackson2HalFormsModule.
Moved quite a few integration tests to the COntextualMapper API.
We now support rendering the type attribute on HAL FORMS properties derived from either an explicit @InputType annotation, derived from JSR-303 annotations (like @Email, @Range etc.), or the property's type as fallback.
Introduced HtmlInputType in a new 'html' package to capture the HTML input types needed for the implementation. That class is used as the default to derive the type based input types via a newly introduced InputTypeFactory registered via the Spring factories loader mechanism for user potentially plugging in a different strategy.
Fixed the contentType in HalFormsTemplate to only contain a single media type.
Also adapted HalFormsAffordanceModelFactory to the new API introduced for #1441.
InputPayloadMetadata now captures and exposes supported media types. SpringAffordanceBuilder obtains them from the newly introduced API available on MappingDiscoverer.
Introduce a new overload in AffordanceModelFactory so that implementations get a single object handed to work with for better extensibility in the future.
Introduced ConfigurableAffordance to be used instead of AffordanceBuilder in assignments and ConfiguredAffordance to separate creation and consumption of affordances during setup.
We now use a ConcurrentLruCache limited to 256 entries instead of a ConcurrentReferenceHashMap to cache Affordance instances to prevent the cache from growing unboundedly before GC kicks in.
Introduce support for the min, max, minLength and maxLength fields for HAL FORMS property descriptors. Extended PropertyMetadata to capture those based on JSR-303 annotations.
Pulled up InputPayloadMetadata.createProperties(…) into AffordanceModel directly. Deprecated InputPayloadMetadata.applyTo(…).
See the spec [0] for details. Significant rework of how an AffordanceModel and HalFormsAffordanceModel in particular translates into creating a representation that matches the affordance (see InputPayloadMetadata.createProperties(…)).
[0] https://rwcbook.github.io/hal-forms/#_code_placeholder_code
