SE702:JavaTableWidget:Interim Report

ALM Table Widget

The "Auckland Layout Model" is a new layout which has been developed @,by, . The benefits of it are.. We aim to produce a table widget which takes advantages of these .. and has a bunch of super duper crasily awesome features.

Many applications use a table to represent a structured set of related material. The basic idea is that rows along a table represent unique tuples, and the columns represent the related fields across each tuple. An example of where a table is commonly used is an address book. The address book may store a group of people each with a phone number, postal address, and email. This would be represented in a table where each of these attributes would have a column ita est;

Name	Phone Number	Postal Address	Email
Rudolf Reindeer	0800REDNOSE	1407230	Rudolf.R@northpole.com
Juliet Montague	XXXXX	XXXXX	XXXXX
John Do	000 0000	01224684	XXXXXX
Cosa Nostra	18481860	4314708	thedon@crime.org

The table representation makes it easier to read and understand the information, than say a crude unstructured list. It is possible to scan columns to get a feel for the variation in values

• We aim to implement sorting functionality which can be done over multiple columns.
• Other stuff

The problems we may face

Design decisions

• To extend or not to extend.

• A table is a list of cell definitions
• A layout consists of tabs + layout specs
• Uses linear programming and penalty values to calculate a layout.

File:SE702-JAVAALMTableWidget-HelloWorld.jpg

https://www.se.auckland.ac.nz/uploads/trReports/UoA-SE-2007-11.pdf

ALM table widget:
Brief description of approach to solve selected features
from the table-widget requirements document.
Planned iteratons/incremental development steps.
Program demonstrating 'hello world' capabilities.

Introduction

The aim of this project is to develop a table widget in Java, using the ALM as it's underlying layout model. It will use linear equations to specify constraints on cells in the table. These equations can be used to allow the definition of a partial order on columns. This can be used to create special tables where the rows have different 'Types'. The requirements of such a table are given in [ref to pdf]. A selection of these requirements has been chosen as possible features to implement.

Approach

The Table Widget will be developed in Java, using version 1.6. It has been decided that the TableWidget class should extend JComponent, so that it can be used in a normal Swing GUI, and contain other normal Swing components. The TableWidget should be able to take it's data and layout information from any class implementing the TableModel interface, so that any data that can be displayed by a swing table, JTable for example, can be displayed by our table widget, without any need for special knowledge of the table widget. In order to facilitate the creation of tables that take advantage of the partial ordering on columns offered by the ALM, a second constructor will take in a TableModel instance, and also a LayoutSpec that constrains the data more.

The logical features we have selected to attempt to solve are(in descending order of priority ):

1 Sorting the table according to one column.

2 Sorting according to many columns in combination (primary, secondary, tertiary... n-ary).

3 Interactive features -> Searching in a column by typing in a text string - have the focus jump to matching cells as you type (For cells containing text).

4 Redundancy free columns - Having duplicate entries in a column span several rows.

5 Strong border - This will likely not be implemented.

Some layout features that will be attempted:

6 Rearranging of columns

7 Resizing and hiding of columns

The number of these features that is implemented by the end of the project will depend on the ease in which the earlier features are achieved. We have no information to allow us to make an estimate on how many we can reasonably achieve.

Implementation plans:

A model-view-controller approach will be taken. The TabelModel instance will provide the model, and the TableWidget will provide the view-controller. This means that to implement sorting, the contents of the TableModel must be copied and sorted, rather than sorted in place, to preserve the integrity of the model.

1 Sorting will be achieved through the use of the bucket sort algorithm as suggested. A copy of the model data will be made, and sorted. The resulting model will be used to update the values of cells in the view

2 Multiple column sorting will be more difficult to implement. A possible approach is that each column stores a boolean value to show if it has been sorted by or not, and a sort index to indicate the order of importance of columns in respect to ordering. For example the primary column sorted by will have index 1, and the secondary column index 2. Both columns will have sorted = true, and other columns will have sorted = false. For the case of sorting by up to n columns, a more complex algorithm will be needed, as bucket sort works only on a single dimensional array. A suggested algorithm has psuedo code like this:

If the column being sorted on is the primary column (has index 1)
       do a bucket sort on this column
If not
       go to the column that was sorted previously (has index > 0 and < the current index)
       look down the column
       for any index i, if the value at index i+1 is = to the value at index i
          keep looking until this is not the case
          bucket sort only these rows according to the column with the current search index 
       if not, increment i and continue

3 Interactive search. This will rely on the column being alphabetically sorted before the interactive search occurs. If this is the case then the search can be carried out by iterating down the cells and using the subString() method on the content of each cell, with the integer argument taken from the number of characters entered in the search box. The complexity of the algorithm is reduced by the fact that once you have iterated 'below' a cell on the table, further iterations can start from there and ignore 'higher' cells.

4 Redundancy free columns. This can be implemented using the power of the ALM, by modifying the YTabs that correspond to cells, so that one cell has a height of several tabs, and the other cells have height of 0 tabs.

6 Rearranging of columns.

7 Resizing and hiding of columns

Development

By necessity the development will be incremental. Several early 'spike' implementations have been developed to test out the feasibility of design decisions. From these we have shown that it is possible to take in data from a TableModel and display it in a table like form, where the rows and columns are constrained by the use of the ALM. The approach taken for this implementation is to store data in an array of row and columns. This approach will not be feasible for extension to the idea of typed rows. In this case, the cardinality of the column headers is not the same as the cardinality of the columns. This requires a more complex mapping and data representation. Further development will be focussed on a table where the rows are all of the same type. This is because it is easier to do, and lessons learnt there will hopefully be portable across to the more complex case.

Hello World

The cells contain JLabels,with text generated from corresponding cells in the underlying TableModel.The column headers are JButtons, also with text from the underlying model. The leftmost column is constrained to adhere to the leftmost edge of the frame. The rightmost column is constrained to adhere to the rightmost edge of the frame. The top and bottom rows are similarly constrained. Each interior row or column is constrained to adhere to the rows or columns adjacent to it. Each column has the same width, and each row the same height. This is automatically generated and will work when passed any tablemodel.