The documentation of CUF is currently mainly done inside the code, so please see the CUF javadoc.

The following overview for the Java-variant of CUF is also included in the download:

Java Swing provides a rich and broad API for a graphical user interface, and (nearly) all applications can be built on top of it.

Swing's main problem (or its main advantage, depending on your point of view) is the lack of structure it provides for an application.

Swing mainly cares about widgets and your interaction with them, but does little to give your application a solid foundation.

The following libraries and frameworks enhance Swing. Both the construction as well as the maintainance of a typical, form-based application should be easier with CUF:

• com.sdm.util.ui (library)
  Some classes for typical tasks, for example the SwingConnectionManager provides a more convienent callback handling.
• net.sf.cuf.ui.table (library)
  Enhanced JTable, esp. for advanced sorting.
  
• net.sf.cuf.state (library)
  Managing of states and the reaction to state changes.
  Useful for describing, aggregating and reacting to the logical states of an application.
• net.sf.cuf.model (library)
  (Smalltalk/Visualworks like) ValueModel, usefull for the data binding between arbitary domain objects an widgets.
• net.sf.cuf.ui.builder (library)
  Non-visual GUI Builder, bundles the above libraries with a declarative XML description of the GUI layout.
• net.sf.cuf.xfer (library)
  Structures the access to the core business logic with built-in mock-up capabilities.
• net.sf.cuf.appevent (library)
  Support of an anonymous event dispatching (receivers don't know senders and vice versa)
• net.sf.cuf.fw (framework)
  Describes what a dialog and an application is.
  
• net.sf.cuf.fw2 (framework)
  Enhances fw by a more detailed life cycle and uses the natural hierarchy of dialogs as a chain of responsibility.

The following steps are needed for the migration:

• the build has changed from ant to maven, so you should now include CUF via maven:
  
• the packages have changed:
  • from com.sdm.util.ui.fw/com.sdm.util.ui.fw2 to net.sf.cuf.fw/net.sf.cuf.fw2 for the framework stuff
  • from com.sdm.util to net.sf.cuf for all other stuff
  • the Dispatcher class was removed, use the Dispatch interface and the SwingDispatcher or JavaFXDispatcher class instead
  • the start() and stop() Methods in Application where renamed to doStart() and doStop() to solve the conflict with the JavaFX Application class.

• A logical dialog is built with two closely coupled classes, that implement the
  net.sf.cuf.fw.Dc
  and the
  net.sf.cuf.fw.Pc
  interface.
  The class that implements the Pc Interface knows the widgets (and perhaps all of Swing), whereas the class that implements the Dc interface knows nothing about Swing and never interacts with widgets or Swing objects (= does not import any Swing package).
• Actions that are not directly triggered by the user (e.g. server access) is done inside the execute-Method of an Request-Object (command pattern).
  Neither a Dc nor a Pc class does know any class (= imports any class/package) that is needed for "server" access, regardless if the server communication is done via EJB, JDBC, Webservice, RMI, CORBA, File, ...
  The result of a Request-object is a Response-object, which is either valid (contains a result object) or invalid (contains an error object).
• An application is represented via (exactly) one object that implements the Application interface.
• The life cycle of the Application/Dc/Pc interfaces contains a defined starting and init of an application, the life cycle of a dialog looks like this:
  

                             
                              init()
     [not exist] -> [created] -----> [initialized]
  
  

• In addition to the Dc/Pc couple, two special Dc/Pc pairs are introduced:
  • a AppDc/AppPc pair manages a top-level non-modal window
  • a DialogDc/DialogPc pair manages a dialog logical below the top level window, either as integrated in that window or as a modal dialog
• The life cycle of the dialogs gets enhanced:
  

                              init()
     [not exist] -> [created] -----> [initialized]
    
                   doActivate()          doPassivate()
     [initialized] -----------> [active] ------------> [passive]
                                         <------------
                                         doActivate()
                dispose()
      [passive] --------> [destroyed]
  

• All DialogDc/DialogPc/AppDc/AppPc objects as well as the DialogApplication object support AppEvents (chain- of-responsibility pattern).
  This provides easy extensability, because a shared information bus exists between all dialogs and the application.
• You can see fw2 in action in the modeltest application in the cuf-swing-examples/src/main/java/com/sdm/cufexamples/model directory.

The CUF dialog concept is modeled after chapter 10 of Johannes Siedersleben: "Moderne Softwarearchitektur", see the book for details.

Unfortunately i'm not aware of any book that focuses on client architecture. If someone knows a good book, please e-mail me!

• Joel Spolsky: "User Interface Design for Programmers" (entry level)
• Steve Krug: "Don't make me think" (Web focus)
• Alan Cooper, Robert Reimann: "About Face 2.0" (advanced level)

• Everett N. McKay: "Developing User Interfaces for Microsoft Windows"

• Kevin Mullet, Darrell Sano: "Designing Visual Interfaces" (advanced level)
• Karsten Lentzsch, http://www.jgoodies.com