Due Date

Mar 22 during the first announced 10 minute break in class, not before, not after. 5% will be deducted for assignments handed in outside this time. You can also drop it into the box until the beginning of class (17:30).

There will be no late assignments accepted.

Note: I recommend starting early on this assignment: it can be tricky.

Marks

10% of your final mark

Purpose

This assignment will give you experience with Sun's Java component architecture called JavaBeans. You will gain some experience in composing components in a composition editor. In addition you will learn the basics for building and packaging beans and gain practical experience in doing it. Some emphasis will be placed on understanding how and why JavaBeans satisfy the basic requirements for being a component architecture.

Readings and Homework

1. Begin by reading Eckel's two sections on JavaBeans (chapter 13, pg 531-574, and chapter 14, pg 621-625). They are not a very thorough introduction to beans or component architectures, but are quite readable and are a good starting point.

2. Read Sun's Tutorial on JavaBeans.

   You will are not required to know the details of bean introspection and reflection (I mentioned it briefly in class). You can thus safely ignore the parts of the tutorial that deal with the "core reflection API", the "Reflection API trail", the "java.beans.Introspector" class, and similar references. You can also omit the section on "Constrained Properties". You do not need to read the "JavaBeans API Specification" document: it is tedious and fairly unilluminating. You don't have to read the sections on "Bean Customization" or "New JavaBeans Features" either.

3. The tutorial leads you through an example of bean construction and use (e.g. the "Writing a SimpleBean" section). You are required to go through these steps. Doing so will greatly simplify doing the assignment, and you can do it immediately.

   These sections are geared towards using Sun's BDK. You do not absolutely need to run or use the BDK to do the tutorial if you have a different composition editor or and IDE with one (such as IBM's Visual Age for Java). If you are thinking of using these in the future, I recommend you doing the tutorial using them in order to get used to them now. However no matter which composition editor you use, you must understand and perform the analogous steps taken to construct, customize, and hook up the beans.

   Note: Sun's JavaStudio apparently does not support certain JavaBeans features, including bound properties. I recommend that you do not use JavaStudio for this assignment.

Preface to Questions

Much of Assignment #2 was about the structure of object-oriented programs. The structuring issues included:

1. How GUIs are hierarchically composed/decomposed using a composition hierarchy of GUI components. The components were java.awt.Component components. They were flexibly composed using java.awt.Container to hold them and the delegation-based AWT 1.1 Event Model to connect them to other parts of the program. Although the composition was done "by hand", this was component composition, nonetheless. AWT components were instantiated, then customized (setFont(), etc.) and then connected through events. We covered this in class, and you needed to know it to create an applet using UI component composition.

2. How the application as a whole was separated into a Model being controlled by (multiple) Controllers and being viewed by (potentially multiple) Views. This was the MVC architecture. In the first part of the assignment you explored how the Model, View and Controller classes could be made reusable by using inheritance or delegation to remove connection information from the main classes and into either sub-classes or delegate classes. We learned that the delegation solution made it possible to connect them at run-time rather than at compile-time.

JavaBeans is a component architecture. It is therefore meant for component composition. JavaBeans consequently provide one answer for structuring an application. The question asked in this assignment is: how can the bean architecture be applied to the structuring issues of Assignment #2?

If UI elements are beans, it should be possible to compose UI elements to generate a UI's composition hierarchy. It might also be possible to compose the non-GUI architectural units if these architectural units could be made to be beans also. In reality, these beans are usually called "non-visual" beans because they are not part of the UI. The coding work that follows explores these ideas.

In all assignment in this course I expect the English to be clear and precise and marks will be deducted where appropriate.

Q1: Making UI Beans

One of the most important functions of the composition editors is to build user interfaces from UI components. UI beans must be subclasses of a java.awt.Component. With a little work, the simple AWT-based classes in the original query applet can be made into UI beans.

1. Convert MaxHitControl and SearchControl into UI beans that each provide a bound property: MaxHitsControl provides a maxHits property and SearchControl provides a query property. Do this by following the following steps:
   1. Both classes have an java.awt.Panel that is returned by getComponent(). Change these classes so that they inherit from Panel rather than have the panel as part-of the class. You will have make some changes to the other methods (e.g. the constructors) to correctly make this change.

   2. The bean now inherits all the methods from Panel. Override the beans' setFont(), setBackground(), and setForeground() so that when these properties are set, it sets the properties of all of its sub-components in addition to its own properties. This way the default customizers for the bean will modify its sub-components. For example, when a MaxHitControl.setBackground() is called, all of the checkboxes will be set to the same colour.

      (You might want to make separate property setters for the colors of the different components in the search control. You would have to add a special customizer for the bean.)

   3. Follow the steps (given in the tutorial) to add support that allows maxHits and query to be properties that can be bound to other beans.

   4. Make sure your bean is serializable. Make sure that only those properties that should be serialized are. You can test out the serialization in Sun's BeanBox within the BDK.

   Rename these two classes AVHitControl and AVSearchControl respectively.

   (Remember you can use Eckel's ch13/BeanDumper.java to introspect your constructed beans. The BDK also has a report generator that can tell report your bean properties and events.)

   (8 marks)

2. Create a manifest file for these classes and package them into a jar file called AVControls.jar. You can test these beans out in your favourite bean editor that supports bound properties. Did you notice what happens when you resize the AVHitControl and run the generated applet?

   Be sure to include your manifest file when you hand in the code listings for your beans.

   (For those of you who are interested, you can see the entire manifest format documentation online).

   (1 mark)

3. The beans you constructed above were composed from standard AWT classes. Many composition editors include the AWT components as UI beans already. Some composition editors allow beans to be composed into composite beans, which can in turn be used as an ordinary bean. Allowing the user to compose beans like this means they can create composite beans, that is, it allows for hierarchical composition. In a sense, the new beans you made are simply pre-packaged compositions.

   Using a few short sentences, give three reasons why it might be helpful (or just better) to have supply users with pre-packaged compositions rather than just allowing users to build them using hierarchical composition in the composition editor.

   (3 marks)

(16 marks total)

Q2: Making and Firing Events

A ResultsModel instance is an object that will generate a set of events when the query text is changed. In the MVC paradigm, the events were generated by notifyObservers and the events were handled by Observers. JavaBeans component architecture uses the AWT 1.1 Event model to perform events. In the JavaBean world, these events:

1. are named and identified by type (i.e. XxxEvent, which is an extension of java.util.EventObject)
2. are registered by specific methods (i.e. addXxxListener())
3. and are fired at listeners of a particular type (i.e. ones that implement XxxListener interface, which is an extension of the java.util.EventListener)

1. Change ResultsModel into an invisible bean as follows:
   1. Change the event generation so that it fires HitEvents at all of the registered HitListeners whenever new hits come in. Yes, you're obviously are going to have to construct the appropriate HitEvent and HitListener classes/interfaces since HitEvent is a non-standard event. Make HitEvent save a reference to the new hit (pass it in during its construction), and provide a getter method for it. Remove the Observable and the Observable-style event generation. (3 marks)

   2. Make the hit, doneQuery, and hitCount so that they could be bound to a target bean. Since hit is an indexed property, add a method to retrieve the entire array (you will have to rename the private field hits to simply hit to conform to the naming convention). Make sure a property change event occurs when setQuery() is called informing that hit property has been updated. Make sure the property change events are fired whenever they change. (3 marks)

   Rename this ResultsModel to be AVQuery.

   (Most composition editors have debugging beans that display events that other beans generate. These can help you debug your bean. In the BDK, it is the EventMonitor bean.)

   (6 marks subtotal)

2. Now AVQuery updates the hits list and fires HitEvent events whenever it updates it. Change ListView into a UI bean that can interact with AVQuery as follows:
   1. Convert the class into a UI component as you did for the controllers, but inheriting from List instead of Panel.

   2. Make the new bean implement the HitListener interface you created for the AVQuery to remember. In your listener method, retrieve the Hit that AVQuery stores in the HitEvent through the getter method and add its title to the list. This replaces the former updateFrom() method.

   3. Add a new boolean property queryDone. In its setter method, do a removeAll() on the list if queryDone is being set to false.

   Rename the class AVList. Now you can hook up AVList beans to AVQuery beans by binding the AVQuery.queryDone property to the AVList.queryDone property and also binding the HitEvents so that AVList has them fired at it. It should be possible to customize and hook up several AVQuery beans that are customized to query different engines.

   (3 marks)

3. Create a manifest file and create a AVQuery.jar file that includes AVList and AVQuery and the support classes. You will need to include the class files in the gnu-regexp-1.0.6.jar also. Read the jar documentation if you are uncertain about how to do this (you will likely have to un-jar the gnu-regexp-1.0.6.jar first). Make sure you hand in your manifest file along with your code.

   (1 mark)

(10 marks total)

Q3: Component Connection

After Part I, you will have effectively created a set of beans that can be hooked up into an applet that is equivalent to the AVQuery applet that was originally provided for you. The difference is that the customization and hookup code can be done in a composition editor rather than "by hand".

Create an applet or application using your composition editor and the beans you created in this assignment such that the structure is analagous to the original MVC-based structure of AVQuery. (You'll have AVQuery, AVList, AVHitControl and AVSearchControl beans hooked up).

Note, you do not need to connect the AVList up so that it makes the browser load the URL specified when an ActionEvent occurs, but that is a good exercise. (See the object hitSelection in the original AVQuery). Also, if you do not wish to create an applet you can create an application instead by downloading and using an applet bean such as Sun's HotJava bean or the Ice Browser Lite bean.

You should not hand this applet in, but use it to answer either question a or question b below.

(If you did an alternate programming project, then you will have composed different UI and non-UI beans together instead, but the principle will be the same).

1. Draw an object interaction diagram for your applet. This should be similar to the object interaction diagram avq-mvc.gif that was given to you in the sample solution to Assignment #2. You must include all listener and adapter objets, all AWT objects, and all bean instances. Label object with their type (class) and method calls between objects with the method names. Clearly show all event sources. Neatness and completeness count.

   Note that in the unlikely case that your composition editor does not generate code that you can read, you should still be able to figure out what is needed since the tutorial describes how connections are made and events are fired. You can refer to the sample code made by BDK and placed in the lecture notes. You can add print statements to you constructors and addListener methods to trace which objects are being passed around.)

2. Write a very short essay (1-3 paragraphs) that compares and contrasts the connections and decomposition of the original AVQuery (which used the Observer/Observable method and the AWT 1.1 events) with the methods used by your composed JavaBeans. In your comparison, consider the following issues:
   1. the mechanisms used for event generation/firing and event listening/reception.
   2. how sub-system elements are created and referenced
   3. the use of standard interfaces and how these affect independent composition. For instance, what are the requirements for using other beans with your JavaBeans as compared to using other classes in the original AVQuery applet?
   Your little essay will be marked based on how well you identify comparable or contrastable features, and how well you execute the comparisons and contrasts.

(10 marks)

Q4: JavaBeans Programming

If you have never written a JavaBean (or other similar components such as a VisualBasic custom control) before this course, write one paragraph (3-6 sentences) describing the most significant difficulty you had in learning how to implement and use JavaBeans. Suggest one thing that could be done to make JavaBeans development easier.

If you have done JavaBean programming before this course (or written other similar components such as VisualBasic custom controls), write one paragraph (3-6 sentences) describing the the most significant problem you feel exists for JavaBeans (as they are implemented in Java 1.1). Suggest one thing that you think can be done to reduce this problem and explain why your suggestion would help.

For either category, your answer will be marked primarily on how well you describe your difficulty and the inventiveness of your answer. Marks will be taken off for answers that are do not earnestly try to answer the question well (e.g. joke answers).

(4 marks)