Due Date

Feb 1 at 17:30. There will be no late assignments accepted.

Marks

4% of your final mark

Purpose

This assignment builds experience in writing applets using AWT 1.1. You will learn how to use the Model-View-Controller method of structuring interactive applications, and understand some facets of what constitutes good OO decomposition for UI design. Students unfamiliar with basics of Java will also benefit from reading other code and developing their own code.

Readings

1. Read Eckel chapter 13, with most of your attention spent on understanding how classes separate code (p. 670-692), and the event model of AWT 1.1. You do not need to remember the details of all the components since you can look those things up when you need it. However you should be familiar with the sort of components available, and how layout is managed. You can ignore the Bean coverage for now (p. 704-721), and only skim the AWT 1.0 stuff at the begining of the chapter (your emphasis should be on the AWT 1.1 for now).

   I recommend doing Exercises 1 and 8 on your own.

2. Read Steve's MVC Introduction

3. Read the JavaWorld Tutorial on MVC and implementing delegation through Observables.

Questions

As per usual for assignment, document all code with javadoc comments, but do not hand in generated .html. Emphasis should be paid to clearly explaining your code and its structure.

1. A simple MVC controller application was presented in class. The source code is located here. It is an updated version of another MVC applet using AWT 1.0, and the original source is here. It is updated to use AWT 1.1 EventListener techniques instead of subclassing AWT components for Button and Label.

   Note that TempModel and TempController are not completely separated in ThermometerMVC318.java since TempController needs to know how to set the temperature.

   • (a)TempController uses an anonymous inner class to set the model's temperature through its tempModel reference. It is possible to remove the need for tempModel in the code for TempController by putting all direct references to tempModel only within subclasses of TempController. That way only subclasses need to know about TempModel. Modify the ThermometerMVC318 applet so that TempController is separated from TempModel through subclassing. Keep the myButton.addActionListener() ( new ActionListener() ... ); call within TempController.

     (Hint: you may need an abstract method in TempController).
     (Hint #2: you may wish to use inner classes when subclassing TempController)

     (3 marks)

   • (b)Subclassing is one way of separating TempModel from TempController. In the original TheremometerMVC318 and your variant in part (a), there is always a direct reference to a TempModel object within the TempController hierarchy. Thus setting the temperature is never delegated to another object. Modify the TempController of ThermometerMVC318 so that it delegates the temperature modification action to another object. Aftwards, neither TempController nor any of its subclasses should be setting the temperature directly.

     (Hint: Your delegate object could implement the ActionListener interface to respond to change requests.)
     

     Compare this second method of separation to part (a). Why might one chose one separation method over the other?

     (4 marks)

   • (c) Give a brief critique of both ThermometerMVC1.java and ThermometerMVC318.java with respect to how well interface and application code are separated in each of these, and how this separation is achieved, if at all.
     (2 marks)

     What effect do the changes you made in part (a) and (b) have on this separation? Briefly explain.
     (1 mark)

     (These issues are discussed in Eckel's coding recommendations (starting pg. 675), and in the other two readings).

   Note, for (a) and (b), the code you hand in should be only those classes that you modified.

2. Internet Search Interface

   (15 marks)

   Internet search engines are required navigation facilities for the WWW. Search engines are database systems that collect and store information about web pages available on the Internet, or within intranets. There are literally dozens of search engines available for free use.

   As we discussed in class, the search engines are clearly indispensible, but there are several drawbacks to how they are currently implemented. One of the main ones is the way they are accessed. As is typical for a database they are accessed through a query language in which the user can specify the type of information they are looking for. The result of the queries is normally a sequence of links to web pages with their titles and descriptions.

   Unfortunately, the standard query mechanism for these databases is almost universally through standard HTML. Queries are entered into a simple text box in a form, and results are returned as a sequence of marked-up HTML pages. In this form the query results are difficult to navigate, manipulate, and work with. The underlying problem is that query results are data, but the results returned by the server is a display of this data in a fixed (and chunked up) form. As a result, the user cannot quickly switch the form of the display, and needs to potentially navigate many web pages to see the results. This can be slow. Moreover further query restrictions require a new search. Besides, most search engines include annoying banners and advertising that many users would prefer not see. You are to build a better (but simple) search engine-result browsing applet as follows:

   1. The applet shall be well-structured according to the Model-View-Controller architecture.

   2. The applet's interface needs to have three basic features:
      1. a place where query text can be placed, and a button to press to submit the query text as a new search.
      2. a list holding the titles of the documents retrieved by the previous search. Double clicking on elements of this list should have the browser load the corresponding target URL.
      3. a way of selecting the maximum number of query results to receive (e.g. CheckboxGroup or TextField).
      The interface should generally follow Altavista's interaction routine of entering a query into a box, pressing a [search] button, and then waiting for the result set to come back. In order to be compatible with most browsers, you must write your UI with AWT 1.1 components using the delegation-based AWT 1.1 event model.

   3. The applet is to querying Altavista as the search engine to consult. It will collect the query results from Altavista and display them for the user. (Note: see below) Code to do the server querying is located here. Despite its limitations, you are not expected to improve this particular code in any way: your mark will not depend on the Altavista querying or the parsing of the query results (but you should have the right calls to these routines in your code).

   4. You will not actually be able to run your applet in a browser and query Altavista. This is due to applet security restrictions that limit connection hosts. In principle your applet could run as designed if you could get Altavista to serve the applet to you since applets are not allowed to connect to hosts other than the one that served them up. However that's not a realistic scenario in this class.

      This should not stop you from completing the assignment. You can use appletviewer to test out the querying, but you won't be able to browse the documents since appletviewer is not a full-fledged browser. Instead of loading the selected target URL, simulate browser action by displaying just the body (Hit.body) of the selected document on the applet window.

   Notes:

   1. In your program documentation, clearly describe how you have structured the program into Model, View, and Controller. Within your writeup include a diagram of the main objects in your system, what events are generated and where, and and how these events are passed between the various objects (it should look somewhat like the event diagram from the MVC lecture).
   2. You do not need to do anything fancy. If it can set the limit, accept the query, query Altavista, show the results in a List, and select entries from the list, that is enough.