todo.naked

Parent Previous

Let's see how the todo application evolves when starting from the functional side. This takes some reverse engineering from the original which was not designed in a domain-driven way. The UI can be split into structural units with properties which are simple to identify:



  1. The application as such (which very obviously should be named "Todos")
  2. A todo item with a title text, a boolean property, if the item is completed, and a method to delete the item.
  3. An ordered list of todo items as a property of the application
  4. A text field in the application to create a new item and add it to the list
  5. A toggle button with hybrid functionality: toggling the completion state of all items and signal if all items are completed.
  6. The footer section which in fact includes two units: A display filter for the list and a function to remove all completed items from the list.


The toggle button is concerned with the items' completion state like the removal button does. So from an OO point of view it makes sense to combine these two parts making up a kind of item state changer. This leads to a OO design of the application like that, using UML notation:



If you translate this design 1:1 to Java code, gengui will create the following UI from that. Sure not yet beautiful, but a structure which reflects the OO model very well:



With the OO model in mind you may now beautify the mask with the JFormDesigner. However, you will probably come to the conclusion that you won't arrange the graphic components in the way they are arranged in the original TodoMVC layout. You had to sacrifice the clarity which the user gains from the clean separation of concerns in the OO model. E.g. why should you combine the Next Item Text field and the All Completed check mark to a line within the table of existing items?? Just to safe space on the screen? They make up different aspects of the application, so why not keep them graphically separated? The beautified UI from the gengui distribution for this example looks like this:



This is the point where you can feel the Form-follows-function principal at work: With gengui and Naked Objects in general it may become really hard to design the UI in a way which is independent from the underlaying business objects' structure. If you permanently need that freedom, you better stick to MVC as you basic architectural pattern. But if you dare to let your business objects rule the UI, you should use the Naked Objects approach and enjoy how UI development speeds up and becomes much simpler than in the past, using the classic heavy-weight patterns.


Created with the Personal Edition of HelpNDoc: Easily create iPhone documentation