Basic frontend collection management #230

jgonggrijp · 2024-10-09T00:46:55Z

While frontend collection handling forms the overarching story of this branch, it is a bit of a hodgepodge of small changes:

Fixed Rewire frontend with backend collections endpoint #224 (restores ability to list and display collections).
- Adjusted existing models, views and other parts to the changed field names.
- Changed the project menu to automatically switch to the project of the current collection, since each collection can now be associated with only one project.
- Made the summary of a collection visible through a <small> insertion in the page header.
- Abolished the conceptual difference between "my collections" and "all collections", because the backend endpoint will never list collections beyond the ones the user has access to.
- Set the idAttribute of the Backbone model that represents a single VRE collection to uri.
Minimally implemented Manage collections from the frontend #225 (create and partial update only).
- Added an inline form to the bottom of the collection menu that lets the user quickly whip up new empty collections.
- Added an inline form that can be temporarily overlaid over the <small> in the page header in order to adjust the summary of a collection.
  - Created a separate, generic, reusable OverlayView in order to support this. It can do one thing: temporarily replace an arbitrary DOM element by an arbitrary view, based on a selector relative to a persistent root element.
Other fixes, refactorings, cosmetic changes and enhancements (mostly just to give myself an easier time while working on the above changes).
- Enabled alt-click debugging for all views (with the exception of views that aren't reachable by mouse, such as OverlayView instances).
- Set the idAttribute of the Project model to name. It appears that the idAttribute was never set to a correct value before this.
- Added an .editorconfig.
- Added temporary files generated by emacs (which I use) to the .gitignore.
- Renamed the "annotation context" menu to just "project", because I felt this conveys the meaning of the menu better.
- Wrote "Collection" instead of "Browse or search" in the header of the collection page, because I think this signals more clearly to the user what they are viewing.
- Added a provisional auto dark mode.
- Removed headlessChrome from the default browsers in the Karma config as discussed in Tests using GitHub Actions #200 (comment).
- Removed the project menu and associated collections from the GlobalVariables, using the vreChannel instead for loose coupling. This brings us a bit closer to Use backbone-fractal and backbone.radio where applicable #123 again.
- Replaced the old, simple but faulty logic for appending trailing slashes to model URLs by the more sophisticated and thoroughly tested modelSlashUrl from backbone-util.

I will be on vacation soon, so I prioritized fast delivery over comprehensiveness. Hence, there are some omissions and rough edges that I am aware of:

Collections cannot be deleted. I think this should eventually be possible, but it needs to be designed carefully to minimize the risk that users accidentally lose a lot of work.
The name of a collection cannot be changed. I opted out of this because I did not want the name and the uri to diverge. In the future, users could conceivably work around this by adding all records from one collection to another and then deleting the source collection.
A project must be selected before you can create a collection. If no project is selected, collection creation silently fails, ~~but an entry with the new name still appears in the menu.~~
There is no validation or error handing for the create and update actions.

There are also things that were already broken on develop and which are not fixed by this branch:

Collections created before Feature/collection api #181 are not visible because of Migrate old-style collections to triplestore #226.
There is no way to add or list records in collections because the records endpoint still has to be updated.
Project selection should probably be more prominent.

For review, I suggest giving the frontend a quick spin and just scrolling through the code changes. There are lots of files with only minor changes, but I think you will be able to quickly identify repeating patterns and skip over those.

As of #181, /api/collections only retrieves the user's own collections by default. The .mine method is retained for easier porting and as an easy way to resume the distinction if it is added again in the future.

This enables the alt-click handler. Eventually, we may want to disable this again in production.

The fact that this was not correctly set yet is a historical artifact that apparently has gone unnoticed for a long time. It is unrelated to #181.

I think this clarifies the meaning.

Just to make the development work less straining on the eyes.

See #200 (comment).

Cf #123, #225.

tijmenbaarda · 2024-10-09T14:51:46Z

A project must be selected before you can create a collection. If no project is selected, collection creation silently fails, but an entry with the new name still appears in the menu.

When I try this, no new entry is added to the menu but an exception project is undefined is raised.

tijmenbaarda

Wonderful! I love the OverlayView. I have just a few comments. I can pick up the things of which you mention that they are still missing in the time that you are away.

tijmenbaarda · 2024-10-09T14:26:52Z

frontend/vre/utils/overlay.view.js

+    },
+
+    toggle: function() {
+        this.cover() || this.uncover();


tijmenbaarda · 2024-10-09T14:42:41Z

frontend/vre/project/project.menu.view.js

@@ -40,11 +40,13 @@ export var ProjectMenuView = CollectionView.extend({
    },

    select: function (model) {
+        model = this.collection.get(model);


Not very clear, I would change the variable name or add a comment

Cf #230 (comment)

This had been broken for a long time. The fix ensures that a project is always selected, which also addresses the "rough edge" discussed in #230 (comment).

@tijmenbaarda

This had been broken for a long time. The fix ensures that a project is always selected, which also addresses the "rough edge" discussed in #230 (comment). CC @tijmenbaarda

jgonggrijp added 20 commits October 8, 2024 20:59

VRECollections.mine() === (new VRECollections).fetch() (#224)

3649886

As of #181, /api/collections only retrieves the user's own collections by default. The .mine method is retained for easier porting and as an easy way to resume the distinction if it is added again in the future.

Make it possible to debug views with alt-click

35952dc

Also debug backbone-fractal views with alt-click

588145b

Set window.DEBUGGING = true

fa97338

This enables the alt-click handler. Eventually, we may want to disable this again in production.

Adjust frontend to changed collection fields (#224)

5b69202

Display the summary in the collection browser (#224)

dcd2c64

Set the idAttribute of the frontend Project model (#224)

163d14a

The fact that this was not correctly set yet is a historical artifact that apparently has gone unnoticed for a long time. It is unrelated to #181.

Automatically switch to the project of the current collection (#224)

abdb5d6

Add a .editorconfig for consistent editor behavior

ae6cf56

Ignore backup files generated by emacs

42c33aa

Rename "annotation context" menu to "project"

ac39f49

I think this clarifies the meaning.

Write "collection" in the header of the collection browser (#224)

54fba8e

Implement provisional auto dark mode

ea47a1d

Just to make the development work less straining on the eyes.

Implement a utility overlay view (#225)

763ad9d

Don't run frontend tests in headless chrome by default (#200)

49c8836

See #200 (comment).

Implement a simple inline summary editing form (#225)

a9c205a

Enable collection summary editing in frontend (#225)

a24fe4c

Refactor global projects to separate module with radio request/reply

72fad55

Cf #123, #225.

Add option to create new collection from the collection menu (#225)

e8ba65e

Add trailing slash to model URLs in the correct way (#224)

63bf97e

jgonggrijp requested a review from tijmenbaarda October 9, 2024 00:46

jgonggrijp linked an issue Oct 9, 2024 that may be closed by this pull request

Manage collections from the frontend #225

Closed

tijmenbaarda approved these changes Oct 9, 2024

View reviewed changes

Add a comment to clarify project menu model normalization (#230)

481deea

Cf #230 (comment)

jgonggrijp added a commit that referenced this pull request Oct 9, 2024

Restore project autoselection (#230)

5829c39

This had been broken for a long time. The fix ensures that a project is always selected, which also addresses the "rough edge" discussed in #230 (comment).

Restore project autoselection (#230)

9e48842

This had been broken for a long time. The fix ensures that a project is always selected, which also addresses the "rough edge" discussed in #230 (comment). CC @tijmenbaarda

jgonggrijp force-pushed the feature/frontend-collections branch from 5829c39 to 9e48842 Compare October 9, 2024 15:58

jgonggrijp merged commit 2d60cf2 into develop Oct 9, 2024
3 checks passed

jgonggrijp deleted the feature/frontend-collections branch October 9, 2024 16:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Basic frontend collection management #230

Basic frontend collection management #230

jgonggrijp commented Oct 9, 2024 •

edited

Loading

tijmenbaarda commented Oct 9, 2024

tijmenbaarda left a comment

tijmenbaarda Oct 9, 2024

tijmenbaarda Oct 9, 2024

Basic frontend collection management #230

Basic frontend collection management #230

Conversation

jgonggrijp commented Oct 9, 2024 • edited Loading

tijmenbaarda commented Oct 9, 2024

tijmenbaarda left a comment

Choose a reason for hiding this comment

tijmenbaarda Oct 9, 2024

Choose a reason for hiding this comment

tijmenbaarda Oct 9, 2024

Choose a reason for hiding this comment

jgonggrijp commented Oct 9, 2024 •

edited

Loading