Add links to nested content properties #1041
Conversation
|
|
||
| It("should add content property links", () -> { | ||
| assertThat(resource.getLinks("child"), hasItems(hasProperty("href", is("http://localhost/contentApi/files/999/child")))); | ||
| assertThat(resource.getLinks("child/content"), hasItems(hasProperty("href", is("http://localhost/contentApi/files/999/child/content")))); |
There was a problem hiding this comment.
I am not completely sure about this link name, any different suggestions or conventions (child.content?) to name links to nested content properties would be welcome.
There was a problem hiding this comment.
I am not aware of a standard for alps links in this regard. What I am doing here is a little bit unique I believe. So, I think it's up to us?
child/content perhaps reflects how the content property as it is addressed when making the request? i.e. http://localhost:8080/contacts/12345/child/content
child.content reflects how the content is fetched internally using BeanWrapper and property editors.
Assuming these links are fetched on the consumer side and '/' will not cause any issues I think I prefer the former?
There was a problem hiding this comment.
If you want to access it from a javascript frontend, both . and / are equally annoying to deal with (You can't do response._links.child.href, but you will have to use response._links["child/content"].href) But that's just a minor concern.
So I think I'll keep the slashes in the link name, as that leaves us with less conversion work.
|
Hmm, trying this out in a real application, it looks like I need to add a test for that case as well, and handle when |
Use MappingContext to retrieve all URLs that are registered for content properties, also for nested properties.
2fb92b7 to
ddceb0b
Compare
|
I worked those issues out last week, and I did not find any new problems with my test application that is using this branch. Can you take a look at it when you have some time @paulcwarren ? |
|
Looks good to me. I have never particularly liked that the mapping context creates two paths for the same content property. And with this now there will be links in the response too. These are backward compatible "shortcut links". I could try and move that implementation code to a better place in the code and wrap it in an From your comments I am guessing your apps will follow the "child/content" link, not the "child" link and you wont care if I do manage to clean up and remove it? |
I'm not entirely sure yet what links that our apps would follow. I am looking into using one |
Use MappingContext to retrieve all URLs that are registered for content
properties, also for nested properties.