Refactor the way export options resulting in oversized dimensions are discovered (for consistency & simplicity)

[Robert Leach]

USE CASE: WHAT DO YOU WANT TO DO?

Simplify code, make it more consistent, and follow MVC design paradigm.

STEPS TO REPRODUCE AN ISSUE (OR TRIGGER A NEW FEATURE)

1. Set export options in ExportHandler
2. Ask ExportHandler for a list of a specific type of options (e.g. AspectType) for enabled/selected choices
3. Create buttons as described in the returned list

CURRENT BEHAVIOR

There are multiple strategies used currently: 1. looping through options while setting them, calculating dimensions, and calling isOversized - at the same time selecting alternative defaults if the pre-selected option results in an invalid/oversized export. 2. Asking for a list of options that are oversized and editing selections in a manner similar to number 1.

All this is done in ExportDialog. There is also some of this done in the controller when options are changed by the user. The code is not re-used by the two. In both cases, some options are set via setters and some are passed in.

EXPECTED BEHAVIOR

When an ExportHandler object is created, it should set defaults using the various getMinDefault methods in the various enums. There should be another method which takes an ExportOptions object and attempts to set the options and returns success. Another method (which already exists) can take an ExportOptions object and sets what it can and should return a modified ExportOptions object. Another set of methods can return a list of options and whether they are enabled (and selected?).

For the case where a user makes a selection and that affects the enabled/disabled state of other options, the cascading update methods are fine, but they could move their logic into ExportHandler to obtain the enabled/disabled state and get a new default selection. These methods could be various versions of isEnabled and getFixSelected(e.g. AspectType).

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

Basically, move all logic about oversized options into ExportHandler (or the controller). Above, I described the things in ExportHandler, but some of that might better go in the controller. The ExportHandler should know what is oversized and what is not. The controller should be where the buttons' state is edited and where defaults are set based on the ExportHandler's identification of what's too big or invalid.

FILES AFFECTED (where the changes will be implemented) - developers only

ExportHandler ExportDialog ExportDialogController (rename to ExportController?)

LEVEL OF EFFORT - developers only

medium

COMMENTS

This came up as issue number 4 in pull request #133.

Be sure to address are*LabelsTooBig methods.