Lab Coding Exercise : GUI Practice

In this lab, you will refactor a forked version of the lab_browser project to clearly separate the "backend" Model (i.e., no imports from javafx.*) from the "frontend" View so it can more easily be varied as new frameworks or new kinds of devices are developed. Then you will add new features to the browser to practice making a Model that returns requested or computed data needed by the View rather than doing the work itself or calling its methods.

In pairs of your choosing, complete the following steps:

1. Setup Pair Programming Environment
2. Review Design Principles
3. Refactoring Refresher
4. Adding and Merging New Features
5. Submit Your Work

Note, there should be a LOT of GIT commits for this lab!

Review Design Principles

Individually, share your interpretation of the Single Responsibility and Open-Closed Design Principles and how they are represented in the refactorings made to the example_roulette and lab_hangman code. Collectively, try to come up with a slogan, catchphrase, or shortened description for each.

Before Moving On: Add your names, interpretations, and slogans to the DISCUSSION.md file, then add, commit the file, and push to your cellsociety_teamNN repository.

Refactoring Refresher: Encapsulating the Model

As a refresher from class this week, refactor the NanoBrowser class to split it into Model and View classes. Use Pair Programming (with three people) to work together within one person's local repository since this is a fairly big and comprehensive change.

Complete this refactoring in the following steps, mostly by moving the existing code to a new class and then calling the new methods in place of the old code:

• Create a new class, NanoBroswerModel, and rename the existing NanoBrowser class to NanoBrowserView.
• Analyze the NanoBrowser class to determine which instance variables should be part of the NanoBroswerModel class and which should remain in the NanoBrowserView class.
  • move the instance variables you decided on to the NanoBroswerModel class and create an appropriate constructor
• move any obvious methods over as well (those that use only the instance variables moved) and change them from private to public
• create new public methods in the NanoBroswerModel class with parts of existing methods that can be separated from the NanoBrowserView class
• Create a new instance variable within the NanoBrowserView class for the NanoBroswerModel
  • update the constructor to receive it as a parameter
  • update the Main class to create an NanoBroswerModel object to pass to the NanoBrowserView when it is created
• Fix the remaining syntax errors in the NanoBrowserView class, such as:
  • those that need to be changed to call the methods that are now in the NanoBroswerModel class
  • those that reference removed instance variables will require the creation of new methods in the NanoBroswerModel class and returning a value that can be used appropriately in the method (be careful not to introduce dependencies on any OpenJFX classes).
• Create two packages, named model and view, and move the appropriate class into each by dragging them graphically — IntelliJ will refactor the rest of the code automatically to correctly import the classes.
• Discuss what values you should return if you cannot return a proper URL (i.e., it does not exist or the given one was malformed).

Before continuing to the next part, use the suggested workflow to integrate the new version of the code with everyone else's copy of the code.

Adding and Merging New Features

Continue practicing using the suggested workflow to complete the following tasks by having each person take one set of tasks and integrating the changes after each step is complete. You are encouraged to discuss the changes with each other as you make them (either for better understanding OpenJFX or to avoid conflicts), but they should be coded independently. Note, the NanoBroswerModel changes should be very small and easy to complete (so most of the time will be spent figuring out the NanoBrowserView changes together) but doing them simultaneously will better help simulate working together in a project.

Submitting your Work

At the end of lab, use Gitlab's Merge Request from your forked repository's master branch back to the original organization repository's master branch to submit your group's answers to the discussion questions and refactored code.

You only need to create one Merge Request, no matter how many commits you make, and you do not worry about potential conflicts since your request will not be approved (it is just an easy way for us to see changes you made).

Make sure the Title of your Merge Request is of the form "lab_browser - everyone's NetIDs".