Closed jimirocks closed 2 years ago
The code does not compile because D extends RepresentationModel<D>>
is required in the signature, not RepresentationModel<?>
. But the only thing a ReactiveRepresentationModelAssembler
implements, is one line of code in the method toCollectionModel
. This original method does not make sense when using JsonApiModel
s because a JsonApiModel
can reprersent a collection model itself.
If you want to use an assembler to create representation models, you can easily build your own, like.
public class MyAssembler {
public Mono<RepresentationModel<?>> toModel(final MyStupidDto entity, final ServerWebExchange exchange) {
return Mono.just(JsonApiModelBuilder.jsonApiModel().model(entity).build());
}
public Mono<RepresentationModel<?>> toCollectionModel(Flux<? extends MyStupidDto> entities, ServerWebExchange exchange) {
// use the builder here to create a JsonApiModel based on entities
}
}
So why would you like to re-use ReactiveRepresentationModelAssembler
at all?
You are right, that we can bypass ReactiveRepresentationModelAssembler
- nothing basically forces us to use that particular interface. So this issue is not anyhow blocking us.
But the fact JsonApiModeBuilder
is not compatible with ReactiveRepresentationModelAssembler
is still here...
@jimirocks
you wrote: But the fact JsonApiModeBuilder
is not compatible with ReactiveRepresentationModelAssembler
is still here...
yes, you are right, but the main reason for that is that those assembler interfaces were designed to work mostly with the build-in EntityModel
and CollectionModel
implementations in mind.
What I was actually thinking about was to create JsonApiModel wrappers to wrap JsonApiModels in EntityModels and CollectionModels, but unfortunatelly it turned to be way more complicated than expected...
Since it is no blocker for you I would close this issue and think further about the wraping :)
yes, you are right, but the main reason for that is that those assembler interfaces were designed to work mostly with the build-in EntityModel and CollectionModel implementations in mind.
Ahh ha so that was the missing piece of puzzle to understand. Thank you for explanation.
We will go with custom interface....
Just fyi, I filed an issue at Spring HATEOAS: https://github.com/spring-projects/spring-hateoas/issues/1796
As I commented on #59 (after close), I believe it should be possible to use
JsonApiModelBuilder
while implementingReactiveRepresentationModelAssembler
but it's not. See the code, which can't compile on the class declaration:I see two possible solutions:
JsonApiModel
public - as suggested in #59ReactiveRepresentationModelAssembler
to<T, D extends RepresentationModel<?>>
from<T, D extends RepresentationModel<D>>