Tools panel should allow generic format mappings

[carlwilson]

The prototype tools panel allows users to map tools to particular formats, currently PDF and Image. Here's a screenshot:

The issue is that the format options are currently hard coded, this can be seen in the Tools module. The code looks as follows:

setAcceptedActions(props.actions, props.fileFormats, 'application/pdf')
  .forEach(item => {
    !PDFArray.find(e => e === item.tool.id.name) ? PDFArray.push(item.tool.id.name) : null;
  });
setAcceptedActions(props.actions, props.fileFormats, 'image/jpeg')
  .forEach(item => {
    !JPEGArray.find(e => e === item.tool.id.name) ? JPEGArray.push(item.tool.id.name) : null;
  });

A similar problem occurs at: https://github.com/openpreserve/jhove2020/blob/master/src/components/Tools/Tools.js#L67

{JPEGArray.map((e, i) => (
  <option key={(i * 2) / 0.4}>{e}</option>
))}
...
{mapTools(tools, actions, 'image')}

The panel should allow the user to create arbitary mappings between formats, tools and actions held in the PAR configuration files. This includes the formats held in [PAR/FileFormats] ./PAR/FileFormats). This will require a "new mapping" button that allows a user to map the concepts then save the mapping.

[bdoubrov]

Yes, Tools pane is indeed hardcoded for the moment. The main question, what exactly it should display. I would suggest to have

• a top level selector (drop down list) for the action type,
• then the list of all formats taken from ./PAR/FileFormats which are supported by this action (similar to how it looks now)
• and for each file format the choice of a default tool and an action for this pair (action type, format)

I believe this correctly reflects your idea, just with one extra supplement: a top level choice for the action type.

[carlwilson]

The question of which entity to drive selection from is interesting. I initially thought format, but that's possibly a bad choice without a good find/filter interface. One thing I'll be looking at is pre-loading data and Formats is the one entity with a lot of source databases we could use. I now think that format is probably a bad choice until we have time to think about UI choices. User feedback would be good for these issues anyway. That leaves Tools or Actions. Given the implementation will currently have few tools, this might be a good place to start? I'm unsure and will get some thoughts here.

One key will be to keep scope down to what we need for an initial release and accept that a more sophisticated UI element will be needed.