Never confuse education with intelligence, you can have a PhD and still be an idiot.
- Richard Feynman -

Assignment:Exposing data over http lab2 GUI Client

From Juneday education
Revision as of 15:54, 21 February 2019 by Rikard (Talk | contribs) (Getting started with Part 3)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Prerequisites - introductory workshop etc

Before starting with this assignment, you should attend the workshop for Lab2, the manuscript for which can be found here and the videos for which can be found here. Read it, and try to understand the GUI and how the Request/Param classes work, as well as how the ApiAccess class works. Se the UML at the last page of the presentation.

The workshop is outlined on the page Workshop Lab2 - The Swing GUI client.

All workshops for this assignment (see course schedule for when workshops are held):

  1. Workshop Lab2 - The Swing GUI client
  2. Workshop Lab2 - Writing a GUI from scratch
  • Source code you need for this assignment can be found here (a zip file with everything)

Lectures to see and chapters to read before starting with this sub-assignment


Exposing data over http, Lab 2

Presentation for the above video channel: Client-side GUI and system

Lab 2 - Writing the GUI Client

In this second sub-assignment, we'll write a small GUI client in Java/Swing. This sub-assignment has two goals: You should have a graphical Java application which can

  • display a table of product from the Systembolaget product line.
  • allow the user to enter values for filtering the products, and produce the correct API call for such filters

Technologies which are the focus of this sub assignment include:

  • Swing
  • HTTP URLs (with GET query parameters)
  • Using factories and interfaces to hide implementations
  • Using fake data to be able to postpone some technical parts of the application, yet be able to test it
  • Printing URLs to verify that the filters are correctly produced from the user interface

Software introduction

Before starting with this task you need to download (and unpack) the software. Use the following link: When unpacking this zip file you will get all the files we refer to below in a directory called exposing-data-lab-gui-master. Enter this directory and start working.

Your client software consists of a few software modules:

  • The graphical user interface
    • Written in Swing
    • Mainly focused around a JTable and a custom JTableModel
  • The domain class Product (represents a Java object for a Product - note that while the Product class is the same as on the server-side, it need not be, since this one represents Products as they are represented by the JSON file)
    • This is the data type for the JTableModel
  • Classes to represent a Query which should be used by some class accessing the web API
    • The Query class represents a set of Param objects, created from the users filter input text fields
    • You'll use a factory to get an ApiAccess object, which let's you access an API
      • An ApiAccess object has a method which accepts a Query object as parameter, and fetches a list of Product objects
    • You'll finish the code for a FakeApiAccess class which always returns the same set of products, regardless of what Query you send it
  • The REST Query class represents a Query (which is what you send to the ApiAccess object)
  • A Query object
    • has a list of parameters (of class Param)
      • A Param (represents a parameter) has a key and a value
    • let's the programmer add parameters to its internal list
    • can return the value from a given key
    • can represent itself as a query string

You'll need to attend (or, in worst case, see the video of) the workshop in order to fully understand the architecture and design of the client. And you need to study some basic stuff, in order to get something out of the workshop.

There's an online API at progund's github for this Lab2 classes.

Swing User interface

The Swing user interface presents the user with a graphical application which lists a set of products in a tabular form. The GUI also presents the user with four input fields:

  • Min price
  • Max price
  • Min alcohol
  • Max alcohol

The GUI will react immediately to input changes in the text fields. In this Lab2, you will print a corresponding URL for the servlet to standard out, so that you can test that the GUI produces a correct query to the servlet from Lab1 according to what the user types in to the GUI.

The table has a table model, which is capable of displaying rows with Product objects, and also sorting the rows (when the user clicks a column header).

In this sub-assignment, you will get the data (products) from an ApiAccess object, sending it a Query. As in lab1, however, you will totally fake the fetching of products. You will create a fake ApiAccess class, which will always return the same objects, regardless of what Query it gets as an argument. The idea behind faking data is to reduce the complexity of the system. In the coming lab (Lab3) we will use proper data from the web API instead.

The first goal of this sub-assignment is for you to see how you can display a table of products in a Swing GUI. We provide a GUI for you. Your job is to understand and extend the gui. You shall also understand how a Query is built and the purpose of the APIAccess interface.

A JTable is used to display the Product data. A JTable uses a "table model" (which we have written for you). You can read about JTable and JTableModel at Oracle: Swing tutorial - how to use tables.

The second goal of this sub-assignment, is for you to verify that the GUI can create the correct Queries for fetching products from the Web API.

Note, that you will not actually contact the Web API from the Java code in this sub-assignment, only verify that your GUI creates the correct URLs for doing so, by printing the URL you would use, and test it manually.

If the user enters 10 in the Min price text field, and 100 in the Max price text field, this should generate a Query for the Web API which reads:


It is enough if your GUI client prints the queries to standard out, for you to be able to test that they are correct and work.

Note, again, that the products displayed in the GUI will not be filtered according to the user input. That's for the third sub-assignment! This is because we don't contact the web API from the GUI code, so we won't get new Products to update the table model with.

This software module is responsible for:

  • Creating a GUI
  • Displaying products in the GUI
  • Allowing for user input in text fields for filtering products

Domain objects

This module (package) only contains the Product class which represents a product from the Systembolaget API. The Product class uses a builder as an alternative to a constructor. You can read about the Builder design pattern here (in particular, the section Making a class have its own builder).

The REST Query API

This module lets you create Query objects (consisting of key-value pairs) which you can send to an ApiAccess object.

An ApiAccess object, should, given a Query, return a list of Product objects. Again, in this sub-assignment, how the ApiAccess object actually fetches the products, is totally fake. Always returning some objects, allows you to test that the GUI is capable of displaying objects in a tabular fashion.

Your GUI will, given input from the user via the text fields, build up a Query which you can print to the standard out to see that it actually creates a URL which would work for accessing the Web API (Servlet).

Directory overview

The directory layout is as follows:

|--   <-- not needed in this lab, Lab2
|-- examples
|   |--  <-- An example GUI without products, showing how you can create a URL from textfields
|   `-- <-- The GUI class for the example
`-- se
    `-- itu
        `-- systemet
            |-- domain
            |   `--
            |-- gui
            |   |--
            |   `--         <-- The central class of the GUI
            |-- main
            |   `--     <-- The main class of the GUI
            `-- rest
                |--  <-- Use this to get an ApiAccess object
                |--     <-- Finish this class to create Product objects for the GUI
                |--             <-- A parameter for a query
                |--      <-- Use this to get a Query object
                `--         <-- Represents a Query for accessing the servlet web API

Part 1 - Building and running the GUI application

Here we simply learn how to compile everything and run the gui application.

We recommend that you use the bash script to compile the client. Read the script and make sure you understand what it does and why it does it.

To run, we recommend the script. Again, read and understand this script.

As usual, you need to make the scripts executable before running them in your terminal running bash. $ chmod u+x *.sh

To compile the example GUI, please do

$ javac examples/*.java

And to run it,

$ java examples.QueryBuilder

Part 2 - Finish the FakeApiAccess class

You will add code to the class FakeApiAccess. This class implements the ApiAccess interface, and which returns a list of fake products when its fetch(Query) method is called. Currently the list is empty, which can be seen if you run the GUI.

A big part of this part is to understand the design and architecture of the gui client provided to you by the teachers.

Faking products you already know how to do, from Lab1.

Part 3 - Printing the generated queries and testing them on the Web API

In this part, you will print the queries generated from the GUI to standard out and use that output to test that the generated query strings actually would work and return the correct JSON from the Servlet Web API.

Part 4 - Add a clear button

Add a button to the search gui. The button:

  • shalll have the text "Clear"
  • be placed in a row underneath the text fields
  • clear the text fields when pressed

Challenge - Part 5

If you want something challenging, you can add a checkbox to the form, indicating that the user is over 20 years. If the checkbox isn't checked (default), the only products allowed are products with alcohol of 0% (max_alcohol=0). Note that this will not affect the products shown, since they are from a fake API access, and the GUI in this lab number 2 doesn't update the product list.

Here are some hints to get you started:

  • Add a private JCheckBox called ageCheckBox as a component
  • Add a private boolean instance variable called is20

In lab 3, if you want to keep this, you need to change the constructor of the SearchGUI class so that it loads only zero alcohol products when the GUI is created.

Some more hints for the init() method:

  • change the form JPanel to be of size 3,4 (three rows and 4 cols)
  • initialize the ageCheckBox to new JCheckBox("I am over 20")
  • add the checkbox to the form
  • add a new JPanel to the form (an empty panel next to the checkbox)
  • disable the alcohol text fields using the setEnabled() method

Some hints for the addListeners() method

  • add an ItemListener to the checkbox
  • in the itemStateChanged(ItemEvent e) method,
    • set the is20 variable to whether e.getStateChange() is ItemEvent.SELECTED
    • if not is20, then set the alco text fields to the empty string
    • set the alco text fields enabled state to whatever is20 is
    • call newFilter()

Another challenge can be to consider any challenges you solved in Lab1. If you e.g. added all or some of the parameters name, product_group etc as valid parameters to the web API, then you can add the corresponding text fields to your GUI so that the user can filter also on name and product_group.

If you didn't do any challenges in the Lab1, then obviously there is no point in adding such text fields here, since they won't work anyway.

Getting started

Getting started with part 1

Setting up your environment

No extra software needed so nothing to do for you.

Build and start your client

In this section we list the steps needed to build the source code. These steps need to be done every time you:

  • want to build (compile) to check that your source code edits were ok
  • run the GUI with the latest changes

To build:

$ ./

To run the GUI:

$ ./

Doing both (the second only of the first is successful):

$ ./ && ./

Note: Expand using link to the right if you can't execute the script.

$ chmod u+x *.sh # make all scripts executable

Getting started with Part 2

Open the file se/itu/systemet/rest/ in an editor and add code to make the method query return a list of (at least) one product. You did this in lab1 so reuse that solution.

Getting started with Part 3

Start by analysing and have a look at the class with the main method, se/itu/systemet/main/ In this main method we can see that the SearchGUI constructor is called. In this Constructor we can see that two methods are invoked, init() and show(). Look at these methods to see where the actionListeners to the text fields are added. This should get you started.

The task is to print the queries generated from the GUI to standard out and use that output to test that the generated query strings actually would work and return the correct JSON from the Servlet Web API.

Hint: A Query object is created, to be used as the argument to the fetch() method of the ApiAccess object. This Query object has a method to give you the query string as a Java String. See the API documentation, in order to figure out what that method is.

Hint: Print the query string together with the first part of the URL for the servlet:

// Pseudo code:
System.out.println("http://localhost:8080/search/products/all?" + query.that_method_which_gives_you_the_query_string());

Why are we doing this step? Because we want you to learn how the code in the GUI and FakeApiAccess works, to prepare you for lab 3. And this particular step is for you to see that you can get the address to the servlet depending on what the user enters in the text fields of the GUI.

Getting started with Part 4

In the previous part you added a printout statement to see the queries. While reading the source code you probably saw that the method init() was responsible for creating and laying out components. We suggest you add code to add the JButton in the same method.

Hint: increase the number of rows in the GridLayout and add a JButton and three empty JPanels to the extra row. The three empty JPanels are added to keep the GridLayout happy.

Optional: add the JButton to a panel and add that to the form instead of adding just a JButton.

About your report

You shall write in your diary (see workshop for details) what you have written and how that code works. You shall also explain how the overall system works and is intended to work.


« PreviousBook TOCNext »