Refactor services dealing with Metadataschemas MetadataFields and Bitstreamformats

[artlowel]

Metadataschemas MetadataFields and Bitstreamformats all use custom response models and services.

This was necessary when they were originally added, because the object cache and dataservices would only support DSpaceObjects.

Now, however you can use dataservices for anything with a self link so we should refactor the responses and services for Metadataschemas MetadataFields and Bitstreamformats formats to use:

• dataservices
• the DSOResponseParsingSerivce and DSOSuccesssResponse (we'll want to rename them to ObjectParsingService and ObjectSuccessResponse)
• and the object-cache.

The idea is that we store the objects in the cache, keep only the links to them in the DSOSuccesssResponse, and retrieve them using a dataservice. Most of this should happen almost automatically.

This way we can remove a good chunk of duplicated code and unnecessary classes for requests, responses and responseparsers, and we ensure that upcoming improvements to the object cache benefit these objects as well.

Estimated amount of effort: 16h

[tdonohue]

@artlowel : Could you link to / describe the "upcoming improvements to the object cache" that you are referencing? That'd help me to analyze & schedule this, as you seem to be implying a dependency here, but it's not entirely clear to me.

I definitely agree this is necessary work, I'm just struggling with where to schedule it as it's unclear what future work or future improvements/features may depend on this refactor.

[artlowel]

I'm referring to the proposal about the cache I'm working on as discussed in the last meeting. I don't have any tickets to link to yet. I will link them after we've discussed it and agreed on the approach.

As it stands, all objects related to the registries don't use the object cache at all. So if we fix edge cases in the object cache, we'll need to fix them again here if we don't refactor first.

The goal is to standardize the way objects are retrieved from rest, have their responses parsed and are stored in the ngrx-store as much as possible, so we can fix the edge cases surrounding this in a single place, rather than having a bunch of slightly different solutions to the same problem.

Registries aren't the only outlier, (the submission is another example) but registries can easily be refactored to work in the standard way because they already work very similarly.

[tdonohue]

@artlowel : Thanks for the additional details. This can be added to beta3 alongside the upcoming cache improvements. However, we can also reschedule for beta4 if needed.