Parent Previous Next

The most advanced variant can be found in directory examples-firststeps/todo/complete. You can start the application by the following command:

java todo.complete.Todos

This variant enriches the one from examples-firststeps/todo/styled by some extensions on Swing level to meet all requirement details.

The domain classes todo.complete.TodoItem implement the interface gengui.util.ViewListener to add hand-written instrumentations to the automatically generated UIs. One of these classes implements a javax.swing.event.ChangeListener to solve the font problem from the solution in section todo.styled.

public class CompletedItemStriker implements ChangeListener {

   static Font normalFont;

   static Font completedFont;

   static Color normalColor;

   static Color completedColor;

   JTextField txtItemText;

   CompletedItemStriker(JTextField txtItemText, JCheckBox cbxItemCompleted) {

       if (normalFont == null) { // Lazy init of fonts and colors

           normalFont = txtItemText.getFont();

           Map<TextAttribute, Object> strikeStyling = new Hashtable<TextAttribute, Object>();

           strikeStyling.put(TextAttribute.STRIKETHROUGH, TextAttribute.STRIKETHROUGH_ON);

           completedFont = normalFont.deriveFont(strikeStyling);

           normalColor = txtItemText.getForeground();

           completedColor = Color.GRAY;



       this.txtItemText = txtItemText;



   public void stateChanged(ChangeEvent e) {

       JCheckBox cbxItemCompleted = (JCheckBox)e.getSource();

       txtItemText.setFont(cbxItemCompleted.isSelected() ? completedFont : normalFont);

       txtItemText.setForeground(cbxItemCompleted.isSelected() ? completedColor : normalColor);




As you see, this is hard-work coding, compared to the simple, business-focused POJO implementation of the domain classes Todos and TodoItem. So the more UI-level instrumentation you introduce, the more you loose the tremendous efficiency boost of a Naked Objects architecture. Before you start instrumenting, you should always ask yourself if you designed your domain classes too poorly to stand for themselves. Or if you are faced with UI requirement details which could as well be changed a bit to come to a better ratio of development effort and user experience. Applied to the todo list application you could e.g. ask for the user's benefit when the edit mode is initiated by double-click rather than single-click.

The instrumentations for the full-featured application take about 220 lines of code which is more than the domain classes' code. These lines can only be tested with advanced UI testing tools or by manual test cases. The good news: Gengui UIs are well-prepared for automated test tools because all UI components have reasonable names and can easily be addressed in the widget tree. This is often a problem in hand-written UIs. Nevertheless, if you come to that point you have more or less left the Naked Objects way.

So at last have a look at the very opposite way explained in section todo.naked.

Created with the Personal Edition of HelpNDoc: Free HTML Help documentation generator