Modified backend and frontend for handling grouping of datasets

[Hardiksh16]

No description provided.

[MichaelRoeder]

Writing "Ungrouped" or "Others" everywhere is not a good way to handle such a problem. Since the group is optional, the classes should offer a constructor without this attribute. The default value (e.g., "Others") should be provided in a static final class attribute.

There are also some other smaller changes needed. Please have a look at the single comments.

[Hardiksh16]

I have read your comments on the code and would refactor them as per your comments @MichaelRoeder

[MichaelRoeder]

There is just a small change request to make things nicer 🙂

[MichaelRoeder]

That is a solution that would work 👍

However, the current implementation handles something that the Spring framework can already do for you. I am afraid that I have described the goal in an ambiguous way, so let me try to explain what I would suggest.
The method should return Map<String, List<DatasetCofiguration>> and the Spring framework should apply it's "magic" to transform it into JSON 🪄

Of course, Spring cannot do magic things, so we still have to provide the serialization 😉
However, it is sufficient if we tell Spring that there is exactly one class that implements the serialization and Spring can simply make use of it whenever it is necessary. You can do that with the method that is shown under point 3.2 in https://www.baeldung.com/spring-boot-customize-jackson-objectmapper (if I am not mistaken, I didn't read the whole text 😅 so let me know if you encounter problems). This method should go into our RootConfig.

[MichaelRoeder]

The UI looks good but I think that we have a general misunderstanding how the workflow to achieve the targeted functionality should look like 😅
So let me bring up my points why I think the current solution is not exactly what it should be...

1. MainController: I do not get, why the controller returns a Map<String, ...>. I assume that is done to make it easier for the UI to show the groups, because the data already comes in the form that the UI would like to have it. However, this is actually not really the task of the controller. If the UI would like to have the data in a certain form, it is free to organize the datasets by groups by itself. It is not really the task of the server to do that especially if we keep in mind that other (future) clients of the API are not interested in the group-wise order of datasets.
2. MainController: the serialization is still explicitly done by ourselves while it should be done by the Spring framework. Yes, we can implement it by ourselves but what should we return in case of an error? At the moment, null is returned but that does not fit to the HTTP standard. So why shouldn't we let Spring do that for us, since it has already implemented all the error handling, etc...

I also added a comment that shows how I imagine it to look like.

[Hardiksh16]

1. Simplified /datasets endpoint, the endpoint now returns List<DatasetConfiguration>
2. Returning 400 instead of null when exception occur.
3. Frontend parses and groups the datasets appropriately and renders on the UI
4. Alphabetically sorts the datasets
5. Wiped out unused code.

[MichaelRoeder]

I just have a small comment. Otherwise, it looks good to me.

[MichaelRoeder]

Should that be super(t);?

[MichaelRoeder]

This is also what the Codacy check marked
https://app.codacy.com/gh/dice-group/gerbil/pull-requests/460/issues#issue-dd4f822d621fb37fa185c60c364e8db0