HW 1 Grading Criteria

General Overview

Most Common Mistakes

• Cannot sort sparse data. This happens if you cannot sort the "hardertest.txt" file found in this directory. Usually this is a problem in the Comparator function.

The Solution

• The real data model (DM) can store the rows in an ArrayList
• The DM fires inserted, deleted, updated events for changes to its rows
• The DM fires structure changed only when a column is added
• The list model (LM) keeps a pointer to the real DM and forwards get operations to it. It listens for events on the DM and forwards appropriate events to its listeners when the columns change
• The filtered data model (FDM) keeps a pointer to the real DM and forwards all get, set, and other data operations to it -- the FDM does not store any real data. The FDM just stores its own row map which figures which subset of the DM is "in" the FDM.
• The filtered data model listens to the real data model for changes, and then recomputes its row map
• When the rowmap is recomputed, the FDM should send a dataChanged for row changes and structure changed only if a column is being added
• The FDM also needs to listen for changes in the text field, and recompute the row map on any change
• When opening or saving a file, a JFileChooser is used to allow the user to specify a location. The resulting File object can be passed on to the constructor for FileReader/Writer for I/O.

1. Add a column (it should show up in the table and sorting JList)
2. Add two rows
3. Put data in second row. Hit return for all cell editing to avoid any Swing focus bugs
4. Set the checkbox filter on
5. Open our two-column test file (easytest.txt) which contains a variety of realistic "foo", "FOO" and "bar" data as well but no blanks.
6. Edit one of the rows
7. Select and delete a row
8. Add a third column
9. Put something in the new column
10. Save an "aaa" test file
11. Type the filter string fOo and note case sensitive correctness
12. Add a column, the filter table should pick up the new column
13. Add a row
14. Add "foo" in the new row -- it should pop down to the filter table
15. Sort by each of the columns. The order should change in both the main table and filter table.
16. Editing inside the filter table, edit a row in the filter table in such a way that it no longer has foo in it -- it should disappear
17. Turn off the checkbox. The text field should disable
18. Quit
19. Check that the saved file. It should look right and not write "null" for empty strings.
20. Open the "hardertest.txt" file with the sparse data using command-line interface.
21. Turn filter on.
22. Put "o" as filter string
23. Sort each column

Major Point Areas

• Basic Functionality (part 1) 50
• DataModel source (uses appropriate fireXXX for the situation) 10
• Can make new columns and the interfaces update 5
• Can add rows and the interface updates 5
• Can load a file and save a file 15
• Can delete rows 5
• Cell editing works in both tables and updates 10
• Sorting (part 2) 20
• List of columns shows up (ListModel source) 10
• Sorting works 10
• Filter view (part 3) 30
• The filtered table shows the right data (and updates correctly for add row, delete row, edit cell, and add column 15
• FilterDataModel source - no copying of data and appropriate fireXXX calls 15

Functionality issues

• Basic Functionality
• Delete should work if there is a selection (we don't test what happens if there is not a selection) -5
• Column name dialog box should appear to allow the user to select the column name -4.
• The save file operation does not work correctly -8
• The load file operation should handle sparse data correctly -7
• Loading files only works from the user's home directory, because the code only pays attention to the name of the file and not its full path -3
• Cannot open a file from command line -3
• JFileChooser does not pop up dialog box from current directory -2.
• Cannot edit sparse data -5.
• Sorting
• Sparse sorting does not work -7.
• Filter view
• The string search should be case-insensitive (use the convert-to-lower functionality in String before searching for the target) -5
• The filter string should update the list on each keystroke. Using the wrong listener on the text field can cause you to get the target string contents _before_ the new character has been inserted -- the correct approach is to listen for "document" events from the text field. This bug suggests too little testing. -5
• The filter table should update when a file is loaded. -5
• When a new row is added and the filter string is added to one of its cells, the row shows up in the filter table -5
• When a row in the filter table is edited so that it doesn't have the filter string in it, then it should remove itself from the filter table. -5
• The filter string text field should disable when the checkbox is cleared -3
• Editing not supported in filter table -5
• Filter table should show all rows when the filter string is empty, or no rows -3.
• Main view should update if filtered model gets edited -3.
• Filter view should display column names correctly -3.
• Filter view only works when search text is upper/lower case -5.

Source code issues

• The coding style, commenting, etc. should be good enough that reading through it does not make the TA wince and feel like taking a shower. For significantly poor looking code, the TA make take off discretionary points or let them off with a warning. Submission errors which cause extra work for the TA get a warning this time, but will get a real deduction for later assignments. The exception to this would be compiling errors, which always results in a deduction.
• DBTableModel
• DBTableModel should fire the "smallest" event possible for each situation. For example, setValueAt() should use fireTableCellUpdated() rather than fireTableDataChanged(). -3..-7 depending on how many mistakes like this there are.
• The fire events should be in the DATA models. The absence of fireXXX events from the data model and their presence in DBFrame violates MVC structure -7. They will lose another -5 because they would have to fireXXXchange in setValueAt. In addition, they also loose the points as indicated above - for not firing smallest event possible.
• Neither TableModel should use a fixed size array to store its rows. Either use ArrayList, or manually grow the array when needed. -5
• The sorting should be implemented using a custom subclass of Comparator and Collections.sort(), unless it's Array.sort (which I okay'ed). -5
• ListModel
• ListModel::getElementAt should pass through the data request to the data model, otherwise the LM is storing data. -10. Maybe -5 if it's only the getSize that violates, but this would be weird.
• FilteredTableModel
• FilteredTM::setValueAt() should pass through the change to the real data model -- otherwise the FTM is storing data. -10 More or less -- judgement call on how much of the FTM assignment constraint has been violated.
• FilteredTM::setValueAt() should not do any fireXXX notifications -- the real data model will take care of that when the setData is passed through to it. The idea here is that the FTM listens for events from the original TM and can rebroadcast them to _its_ listeners (for example, the filter table). If you don't refire the events, then the filter table won't work. If you fire events in setValueAt() then you are either double firing events, or you don't quite have the architecture right.; -2 to -5
• FilteredTM should not fire structure changed in response to simple row data updates -- there should at least be some attempt to distinguish row data from structure changes. One way to tell if a change event requires a structure change is by testing if the column is == TableModelEvent.HEADER_ROW. -5