- edited description
Create single scale button actions and delegate MapContainer logic to MVController
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
Comments (5)
-
reporter -
- changed milestone to Coding Convention Adherence
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.
-
- changed component to Coding Convention Adherence
-
- removed milestone
Removing milestone: Coding Convention Adherence (automated comment)
-
- changed version to beta2
- Log in to comment