spring-hateoas
spring-hateoas copied to clipboard
spring-projects
Add a template variables contribution SPI
Add a template variables contribution SPI to resolve issues such as #706 This is also a first step (in a 2 steps process) to treat https://github.com/spring-projects/spring-data-commons/issues/2168
Hello,
The underlying issue (https://github.com/spring-projects/spring-hateoas/issues/706) seems critical for anyone hopping to use hypermedia pagination with filtering criteria. For a year now, I have been maintaining a forked version of Spring HATEOAS and Spring Data Commons (containing this change and its implementation) to make this work on our main project.
Please help me fix this issue upstream :pray:
@odrotbohm , @gregturn is there a reason related to the proposed change explaining why I have had no feedback for 3 years?
Because of this, I have been dragging 2 forks on production for 3 years through all Spring major versions. One for this project, the other for https://github.com/spring-projects/spring-data-commons/issues/2168 .
Not at all, except that it somehow has slipped our radar. From a quick glance at the SD Commons issue I can tell, that, generally speaking, as of SD 2.0, null values for Pageable have become invalid and have to be replaced by Pageable.unpaged(). I'll see whether we can be a bit smarter in the DummyInvocationUtils to maybe treat a null Pageable special. I can see that it would be more convenient to just signal absence of pagination information by using a plain null in that particular case.
I'll investigate on Tuesday but can also say that the absence of pagination information in an original request is properly handled by, for example, Spring Data REST. That makes me doubt that we have a fundamental problem which needs a fork to make that work. But then again, I might be wrong of course. Expect some judgement on the overall situation soon.
And again: sorry for the delay and thanks for your patience.
I'll investigate on Tuesday but can also say that the absence of pagination information in an original request is properly handled by, for example, Spring Data REST. That makes me doubt that we have a fundamental problem which needs a fork to make that work.
From what I read around https://github.com/spring-projects/spring-data-rest/blob/e9c43f1373b68c31c14985e189e31ad0a0af31e1/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/support/RepositoryEntityLinks.java#L122, that would be because Spring Data REST doesn’t use WebMvcLinkBuilderFactory to create those uri templates.
@odrotbohm sorry to bother you again with this 🥹 I’d like to move to Spring Boot 3.1.0 without those forks ^^
Reda, this is not helpful. I wrote ASAP. There's other stuff we're busy with. Furthermore, as this will be a significant change and like causes downstream effects on projects like Spring Data REST, we can only ship this in a minor version cycle. I.e., the first milestone version this can reasonably go out in will come mid-July, GA in autumn. Thanks for understanding.
I understand Oliver. Thank you for providing those details. I’ll keep syncing my forks until then 🙂