Programming Exercise: NanoBrowser

This exercise is intended for you to practice:

• using Java packages and separating a program's model from its view
• writing tests for the model
• catching Exceptions
• organizing OpenJFX's interaction components into different layouts
• creating inheritance hierarchies.

It will not be explicitly graded but, instead, serve as a starting point for us to see your coding strengths and weaknesses (and how well you follow directions). Thus, you will get the most out of this assignment by putting in a good faith effort.

Submission

You will be provided a GIT repository, browser_NETID, hosted in the course's Gitlab group to work on this project.

As your submission for this project, use GIT to add, commit, and push the following to your repository:

• src folder: project code
• top-level (no separate folder): project README

Your code is expected to follow the course coding conventions and be reasonably commented.

Specifications

Individually, build on the lab exercise to refactor the existing code from a single class that does not follow the Single Responsibility Principle (by mixing the logic for managing URLs with the OpenJFX framework for displaying and selecting them) into multiple classes in separate model and view Java packages. The program's main() method should create the primary class for each package and connect them appropriately. It is justifiable design for the view classes to have model classes as instance variables and call their public methods (because model classes are typically viewed as more "stable" concepts in the problem being solved), but it is generally not a good design practice for model classes to call view class methods (because view technologies are considered "unstable" since they change often). Instead the model should communicate with the view by returning objects or throwing Exceptions.

Model

After you have completed this separation for the basic implementation (just the Go and History features), you should add additional features to the browser such that their logic is appropriately separated as well:

• allow the user to set a specific website as a Home page (throws Exception if used when Home is not set)
• allow the user to keep track of their Favorite websites by name (throws Exception if no name is given to set Favorite or if an unrecognized name is given)
• allow the user to select from their Top Sites (i.e., their most frequently visited)
• any other browser-oriented feature you want

For more of a challenge, you can start experimenting with the Open-Closed Principle by representing these features as variations of an abstraction that organizes URL(s) based on taking an action whenever the current URL in the model changes or activated by the view.

You are strongly encouraged to write active methods for the model class, rather than passive getter/setter methods, that hide details, validate data, represent concepts, and may be overridden by possible subclasses.

Testing

Provide test class(es) with JUnit test methods and assertions that attempt to verify your model works as intended (we will learn about testing the view in the future). Generally, aim to create a test class for each of your concrete classes with at least two well named tests for each non-trivial public method (more than two are expected for complex methods). Another check is to try to achieve at least 75% Line test coverage of the class.

View

Practice experimenting with different OpenJFX components and the events they generate in providing the user an interface for the features above, such as:

• Button(s) to set the current page as the Home page (e.g., a single button could change its title from "Set Home" to just "Home")
• TextInputDialog to get the user's name for the current page a Favorite, then a ChoiceBox or ComboBox to select from those names
• ListView in a separate panel or a SplitMenuButton to display the Top Sites
• HTMLEditor to edit the loaded page!
• ToolBar instead of an HBox or VBox only
• Tabbed browsing (this requires having multiple instances of the model)!
• MenuBar for actions such as New Tab, Close Tab, and Clear for each/all features (History, Home, Favorites, Top Sites)

You can also experiment with useful component features to help prevent possible user errors:

• disable buttons when their actions would lead to errors (e.g., the current implementation throws an IndexOutOfBounds exception when the Back or Next buttons are used and there is no history)

Note, if you created an abstraction for your model features, then you will likely want to create a similar one for your view so that whatever you chose to display that feature has direct access to the concrete type if needed. Representing groups of components (e.g., a label with a text field, or a group of buttons, or dialog box and combo box) as their own class in your view package is a practice to develop to keep the display code as clean as possible.