When is using XML based configuration files preferable to using source based interfaces and/or classes? I’ve been taking a look at command frameworks such as those that come with the various rich client toolkits out there, and also GUI Commands. It struck me that many things which I would allow via a concrete class or an abstract base class these frameworks try to push out into XML files. I can see that XML could be good for huge apps such as, for example, Eclipse, where the developers want to provide extensibility without a huge class loading overhead.

But most of these rich client kits are designed to be used to create small to medium sized applications and if this is what you are doing then I don’t see the point of scattering configuration information around the place, it’s better to keep it all together and the only place that this can happen is right there in the source code.

One final argument for keeping some of this external is for easy internationalisation, but this can be achieved simply using standard Java resource bundles or Eclipse style NLS libraries (I prefer the eclipse style NLS approach as it makes code more readable).

This is a really cool idea (and not at all what you’d expect to find on a website called Play Pumps)! It’s a kid’s roundabout that also acts as a pump for a fresh water well. They’re definitely getting some cash from me.

I’ve noticed a neat feature in Path Finder where it changes the date format used to display time stamps in the main table based on the width of the column. In RvSnoop I was allowing the user to set a preferred format as a configuration option, but this seems much better. It turns out that this is pretty easy to achieve in Java, just use the following class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

public class DateCellRenderer extends DefaultTableCellRenderer {
    // Or load these from a user preference...
    private static final DateFormat[] dateFormats = {
    new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS"),
    new SimpleDateFormat("yy-MM-dd HH:mm:ss.SSS"),
    new SimpleDateFormat("MM/dd HH:mm:ss.SSS"),
    new SimpleDateFormat("HH:mm:ss.SSS"),
    new SimpleDateFormat("HH:mm:ss.SS"),
    new SimpleDateFormat("HH:mm:ss.S"),
    new SimpleDateFormat("HH:mm:ss"),
    new SimpleDateFormat("HH:mm") };
    private int currentWidth;
    private Font currentFont;
    private DateFormat currentFormat;
    private final Date date = new Date();
    public Component getTableCellRendererComponent(JTable table, Object value,
    boolean isSelected, boolean hasFocus, int row, int col) {
        DateFormat format = getFormat(table.getColumnModel().getColumn(col).getWidth(), table);
        String displayed = value != null ? format.format((Date) value) : "";
        return super.getTableCellRendererComponent(table, displayed, isSelected, hasFocus, row, col);
    }
    private DateFormat getFormat(int width, JTable table) {
        Font font = table.getFont();
        if (currentWidth == width && currentFormat != null && font.equals(currentFont)) {
            return currentFormat;
        }
        currentWidth = width;
        currentFont = font;
        FontMetrics metrics = table.getFontMetrics(font);
        date.setTime(System.currentTimeMillis())
        for (DateFormat df : dateFormats) {
            if (metrics.stringWidth(df.format(date)) < width) {
                currentFormat = df;
                return df;
                }
            }
        }
        currentFormat = dateFormats[dateFormats.length - 1];
        return currentFormat;
    }
}

You will need to register it with your JTable via myTable.getColumnModel().getColumn(0).setCellRenderer(myRenderer); and away you go. You can have more or less format options by altering the static array in the class.

I’ve taken over pretty much all of the development of the rvSnoop utility now, the first major new release has been put out today with a number of changes in it. Here, briefly, are the plans for the next few versions:

• A graphical widget to display messages instead of the text field.

• More import/export formats for messages.

• General user interface clean-up.

• Better documentation. I’ll have more plans once I get to know the code a little better.

• Add a new action to delete connections.

• Add support for viewing serialized Java objects.

• Move the preferences to a separate dialog.

• Add support for editing messages before republishing.

Along with some more code cleanup. After that I’m planning to push for a 2.0 release which should contain a much more robust export mechanism, persistent record ledgers, and graphical charts. Finally, once the code settles down a bit I’m going to look into supporting EMS messages (as a separate project, emsSnoop).

I’ve moved this site to a new host, at TextDrive. Unfortunately it didn’t do as smoothly as I’d like (all my fault, as well!). It may take a day or two to get all of the old entries imported and the other site pages loaded again. Doh!