Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Browse by date and Starts-With component #364
The purpose of this PR is to add a Browse-By page for date fields as well as adding a Starts-With component to all Browse-By pages.
Currently, the only date field using this component is "dc.date.issued" a.k.a. "dateissued". The route to this page can be found at
Two new components have been added: StartsWithText and StartsWithDate, both extending from an abstract component StartsWithAbstract.
These components come with a decorator
The StartsWith component adds a
paulo-graca left a comment
Thank you @Atmire-Kristof for this contribution. Overall, to me, it's a good as is. But I've the following requests:
tdonohue left a comment
@Atmire-Kristof : I gave this a quick review this morning. The code is looking good, and thanks for all the TypeDocs/comments in your code! I found one interface where I'd appreciate TypeDocs being added.
I haven't had a chance to test this out, but will do so later today.
@Atmire-Kristof and @artlowel : I've tested this today. While the StartsWith & Browse By Date functionality seems to work fine overall, I've got some concerns/questions about the design approach here.
All of the points you noted are consequences of how the rest side works I'm afraid:
When using the startsWith param, the rest api will return the exact same pagination info for any item that would be on the same page if startsWith wasn't used. So if normally the first Title starting with 'S' would be the fourth item on the 15th page, then the pagination object the rest api returns when you ask for
Again that's determined by what the rest api returns. I agree that it would be nice to make this more consistent, but this seems to be exactly the way it works in dspace 6 as well:
@artlowel : thanks for the clarifications here. I agree that it sounds like the third point is current behavior (so I'll withdraw that).
However, my first point is a change in behavior from DSpace 6.x. In DSpace 6.x we are able to display a "Now showing..." option even after jumping to a specific letter. For example, here's Browse by Title starting with "D" in the XMLUI: http://demo.dspace.org/xmlui/browse?rpp=20&etal=-1&sort_by=1&type=title&starts_with=D&order=ASC
I definitely understand that this PR isn't at fault for that change in behavior. But, I wonder if we can log this as a known bug and figure out a way to fix this in the REST API (and a future Angular UI PR) -- perhaps you could brainstorm with @benbosman on this? If we feel it's nearly impossible (or very hard) to retain that "Now showing..." text, then I feel we need some other sort of contextual information (in the UI) that helps the user figure out what this component is doing.
Currently, as I noted, the behaviour was even confusing to me (a DSpace expert). For example, in testing this PR, I went to Browse by Title and clicked on letter "F". As I had no titles starting with the letter "F", the first title I saw began with "H". I initially thought it wasn't working correctly, until I realized that what was going on. However, realizing what was going on was difficult, cause there was no way to page backwards. I literally had to clear out my search and double check if I had any titles starting with "F". So, I'm worried this UI currently has some significant usability issues (again, not really a fault of this PR alone).
So, in summary, I'm OK with accepting this PR as-is (since it seems to "work") if we can develop a plan to improve it in the future. I'd like that plan to be documented (as best we can) in tickets. We could also discuss it further in next week's meeting (as a discussion topic) if necessary.
(As a sidenote, this PR now has minor merge conflicts related to the merger of the Administrative Edit PR.)