Add step when installing applet to optionally add configured dimensions

[adaburrows]

After #154 we need a separate step to configure dimensions in the same manner of our current dimension config screen. Make the screen as similar to the dimension config screen as possible, and highlight the new dimensions. The "save" button should say "Yes, add dimensions" and cancel should say "No thanks".

[adaburrows]

New Criteria

When adding a dimension from a config we need to check to see if some essential portion of a dimension overlaps with another on that already exists. Since we have no UX designer, this should be as simple and text based as possible until we can revise the design. Remove all tables for the display for now.

This problem takes the form of a lattice (partially ordered set):

1. Complete I/O graph overlap. All of {name, range} of input dimensions and {name, range, operation, and input dimension} of output dimensions from config intersect with existing dimensions. Should inform user that the dimensions are not being created from the config since the configuration already exists.
2. Partial I/O graph overlap.
   • Allow individually selecting input and output dimensions that do not intersect.
   • For each input dimension from the config that intersects {name and range}, do not create.
   • For each input dimension from the config that has the name of an existing input dimension, allow renaming the incoming dimension.
   • For each input dimension from the config that has the same range as an existing input dimension, allow choosing the existing dimension. If and output dimension uses this input dimension, update the output dimension.
   • For each output dimension from the config that intersects all of {name, range, operation, and input dimension} of existing output dimensions, do not create.
   • Output dimension has name that intersects an existing output dimension, allow changing the name.
   • Output dimension has range that overlaps an existing output dimension, allow choosing the existing dimension.
   • Output dimension has input dimension that intersects an existing input dimension, allow editing to use existing dimension that overlaps in range.
   • Always coerce output dimension range to correct range based on chosen input dimension.

[nick-stebbings]

• [x] 1. Complete I/O graph overlap

2.

• [x] Allow individually selecting input and output dimensions that do not intersect.
  • [x] For each input dimension from the config that intersects {name and range}, do not create.
  • [x] For each input dimension from the config that has the name of an existing input dimension, allow renaming the incoming dimension.
  • [x] For each input dimension from the config that has the same range as an existing input dimension, allow choosing the existing dimension.
  • [x] If an output dimension uses this input dimension, update the output dimension. NOTE: (Above works now for the simplest case, but gets complicated quickly and I think we need to break this down more before going further - it might be worth developing some universal util functions for comparing equality of output dimension/method pairs.)
  • [x] For each output dimension from the config that intersects all of {name, range, operation, and input dimension} of existing output dimensions, do not create.
  • [x] Output dimension has name that intersects an existing output dimension, allow changing the name.
  • [x] Output dimension has range that overlaps an existing output dimension, allow choosing the existing dimension.
  • [x] Output dimension has input dimension that intersects an existing input dimension, allow editing to use existing dimension that overlaps in range.
  • [x] Always coerce output dimension range to correct range based on chosen input dimension.

[adaburrows]

@emalinus, here is the product question: Should do the full lattice (every bit of logic I wrote above) or if we should just have a simple rule that states that if there is a complete or partial intersection, one or more fields has the same value, we should not create any conflicting parts of the graph or any part that depends on a conflicting part.

While we still need to make roughly the same code to compute intersections, we don't have to do as much with the UI and could wait for further feedback from the UX hire later.

[nick-stebbings]

Always coerce output dimension range to correct range based on chosen input dimension.

@adaburrows by this do you mean implement the same logic as the dimension creation form w.r.t range limits?

[emalinus]

@emalinus, here is the product question: Should do the full lattice (every bit of logic I wrote above) or if we should just have a simple rule that states that if there is a complete or partial intersection, one or more fields has the same value, we should not create any conflicting parts of the graph or any part that depends on a conflicting part.

While we still need to make roughly the same code to compute intersections, we don't have to do as much with the UI and could wait for further feedback from the UX hire later.

The rule not to create conflicting parts of the graph or dependencies on those conflicting parts seems to only obviate the bits above if the configuration is per resource. Is this the case?