adjust representation of different output products

[volodymyrss]

Following the discussion there, from the comment of @dsavchenko .

The output as produced by the plugin is in most cases structured like the one for the image. I chose this way so that every product type is ingestible by the frontend without additional changes there.
But this leads to misunderstandings, as we see. From showing products list as a table of "Images" to almost useless "download" button for simple text output etc.
We may want to adapt the frontend to better represent different products. Using it then will require rather small changes in the plugin.

[dsavchenko]

Shouldn't this issue be in the frontend repo?
(What we need here is a follow up)

Also, I'm not sure I have enough experience with frontend js code to be the only one assigned

[volodymyrss]

I thought you'd make changes to methods like here?

Or you meant some other adjustments to the frontend?

The title of this issue is pointing to frontend, I will change.

[dsavchenko]

There are three different representations in the frontend depending on the dispatcher response structure (and there is also a dependence from dataproduct name in some cases afair) -- image, lightcurve, spectrum.
Nb2workflow plugin represents most data (apart from lightcurves, we never tested an OGIP spectra there) in the same form as images.
Coordinated changes are needed on both ends to better represent arbitrary dataproduct types.

Anyway, it's better to start from defining API changes/extension. Maybe accompanying issue in the dispatcher to track it is needed.