Create single scale button actions and delegate MapContainer logic to MVController

[Christopher Keil]

USE CASE: WHAT DO YOU WANT TO DO?

Invoke an Action when the user presses a scale button.

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

CURRENT BEHAVIOR

Scaling logic on MapContainers is invoked directly in DendroController's ScaleListener. This is incorrect since DendroController shouldn't directly control the matrix. That is MatrixViewController's job.

EXPECTED BEHAVIOR

Create one ActionListener for each scale button.

DEVELOPERS ONLY SECTION

SUGGESTED CHANGE (Pseudocode optional)

invoke logic via MatrixViewController by calling in the button's ActionListener in DendroController (for example)

mvController.updateXYMinus(e.getModifiers()) 

where updateXYMinus(int modifiers) will simply execute the scaling logic in mvController such as

public void updateXYMinus(final int modifiers) {

        if ((modifiers & InputEvent.META_MASK) != 0) {
            resetMatrixViews();
            imView.setAspectRatio(
                    interactiveXmap.getTotalTileNum(),
                    interactiveYmap.getTotalTileNum());

        } else if ((modifiers & InputEvent.SHIFT_MASK) != 0) {
            interactiveXmap.zoomOutCenter(MapContainer.ZOOM_FAST);
            interactiveYmap.zoomOutCenter(MapContainer.ZOOM_FAST);

            } else if ((modifiers & InputEvent.ALT_MASK) != 0) {
                interactiveXmap.zoomOutCenter(MapContainer.ZOOM_DEFAULT);
                        interactiveYmap.zoomOutCenter(MapContainer.ZOOM_DEFAULT);
        }
}

Checking for e.getSource() is not needed if each button is assigned its own ActionListener.

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

DendroController.java, MatrixViewController.java

LEVEL OF EFFORT - developers only

minor

COMMENTS

[Robert Leach]

This is a coding convention adherence issue. Software Engineering issues are those that relate to the processes which govern how we operate on an organizational level, e.g. change control procedures, requirements gathering procedures, selection of design paradigms, development of testing procedures, etc.. While these might include a statement of what design patterns to follow (e.g. MVC), issues about adherence to a particular design paradigm are separate issues (e.g. coding convention adherence). If the issue is to change something about the MVC design pattern selection, then it would be a Software Engineering issue. If the issue is to change something about the code to stick to a selected design pattern, then it's a coding convention adherence issue.

Note, we haven't incorporated a formal design phase, though we have implicitly adopted MVC design. If you want to formalize the implicit adoption of MVC, it would be a change to the SCMP document or the addition of another document in the softeng directory.

[Robert Leach]

Removing milestone: Coding Convention Adherence (automated comment)