diff options
| author | Benjamin Culkin <scorpress@gmail.com> | 2024-05-20 17:55:46 -0400 |
|---|---|---|
| committer | Benjamin Culkin <scorpress@gmail.com> | 2024-05-20 17:56:12 -0400 |
| commit | ff072dfe782f6f22123cd4ba050828d35c0d0fbd (patch) | |
| tree | 1e2c9e86252dcba86f72fb629ef4d6f68f73cd2c | |
| parent | d1378716fda89e48450b7ca1333b505d800504a5 (diff) | |
Some lingering tweaks
15 files changed, 1047 insertions, 780 deletions
diff --git a/projects/.gitignore b/projects/.gitignore index 430b1ae..bb72b6f 100644 --- a/projects/.gitignore +++ b/projects/.gitignore @@ -1,3 +1,4 @@ .classpath .project .settings +../.svn diff --git a/projects/net.wotonomy.all/src/site/build.xml b/projects/net.wotonomy.all/src/site/build.xml index a71e2fb..4d2856b 100644 --- a/projects/net.wotonomy.all/src/site/build.xml +++ b/projects/net.wotonomy.all/src/site/build.xml @@ -1,175 +1,214 @@ -<?xml version="1.0" encoding="utf-8" ?> +<?xml version="1.0" encoding="utf-8"?> <project name="wotonomy" default="build" basedir="."> - <!-- - <taskdef name="junit" classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask" /> + <!-- + <taskdef name="junit" + classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask" /> --> - <!-- + <!-- Sets the compiler property. Options are "classic" or "modern" or "jikes". --> - <property name="build.compiler" value="modern"/> - <property name="project.dir.src" value="${basedir}" /> - <property name="project.dir.src.main.java" value="${project.dir.src}" /> - <property name="project.dir.src.test.java" value="${basedir}/src/test/java" /> - <property name="project.dir.target" value="${basedir}/target" /> - <property name="project.dir.classes" value="${project.dir.target}/classes" /> - <property name="project.dir.test-classes" value="${project.dir.target}/test-classes" /> - - <property name="project.dir.resources" value="${basedir}" /> - - <property name="project.dir.lib" value="${basedir}/lib" /> - - <property name="project.dir.javadoc" value="${project.dir.target}/javadoc/api-docs" /> - - <property name="project.version" value="0.5-SNAPSHOT" /> - - <property name="package.jar.filename.prefix" value="${project.dir.target}/${ant.project.name}" /> - <property name="package.jar.filename.suffix" value=".jar" /> - <property name="package.jar.filename" value="${package.jar.filename.prefix}-${project.version}${package.jar.filename.suffix}" /> - - - <!-- + <property name="build.compiler" value="modern" /> + <property name="project.dir.src" value="${basedir}" /> + <property name="project.dir.src.main.java" value="${project.dir.src}" /> + <property name="project.dir.src.test.java" value="${basedir}/src/test/java" /> + <property name="project.dir.target" value="${basedir}/target" /> + <property name="project.dir.classes" value="${project.dir.target}/classes" /> + <property name="project.dir.test-classes" + value="${project.dir.target}/test-classes" /> + + <property name="project.dir.resources" value="${basedir}" /> + + <property name="project.dir.lib" value="${basedir}/lib" /> + + <property name="project.dir.javadoc" + value="${project.dir.target}/javadoc/api-docs" /> + + <property name="project.version" value="0.5-SNAPSHOT" /> + + <property name="package.jar.filename.prefix" + value="${project.dir.target}/${ant.project.name}" /> + <property name="package.jar.filename.suffix" value=".jar" /> + <property name="package.jar.filename" + value="${package.jar.filename.prefix}-${project.version}${package.jar.filename.suffix}" /> + + + <!-- Builds the entire wotonomy package. Requires ognl.jar, servlet.jar, xerces.jar, and xp.jar. --> - - <target name="build" description="Build all sources and build the library" depends="clean,test,package-libraries" /> - - <target name="compile-main"> - <javac destdir="${project.dir.classes}" - includes="**/*.java"> - <src path="${project.dir.src.main.java}" /> - <exclude name="src/**" /> - <exclude name="target/**" /> - <exclude name="docs/**" /> - <exclude name="${project.dir.lib}/**" /> - <classpath> - <pathelement location="${project.dir.lib}/servlet.jar" /> - <pathelement location="${project.dir.lib}/xp.jar" /> - <pathelement location="${project.dir.lib}/xerces.jar" /> - <pathelement location="${project.dir.lib}/ognl.jar" /> - </classpath> - </javac> - </target> - - - <!-- + + <target name="build" description="Build all sources and build the library" + depends="clean,test,package-libraries" /> + + <target name="compile-main"> + <javac destdir="${project.dir.classes}" + includes="**/*.java"> + <src path="${project.dir.src.main.java}" /> + <exclude name="src/**" /> + <exclude name="target/**" /> + <exclude name="docs/**" /> + <exclude name="${project.dir.lib}/**" /> + <classpath> + <pathelement location="${project.dir.lib}/servlet.jar" /> + <pathelement location="${project.dir.lib}/xp.jar" /> + <pathelement location="${project.dir.lib}/xerces.jar" /> + <pathelement location="${project.dir.lib}/ognl.jar" /> + </classpath> + </javac> + </target> + + + <!-- Generates documentation for all wotonomy packages. --> - <target name="docs" depends="javadoc" description="Original doc generation target (deprecated)" /> - <target name="javadoc"> - <mkdir dir="docs" /> - <javadoc sourcepath="." destdir="${project.dir.javadoc}" - packagenames="net.wotonomy.control.*,net.wotonomy.foundation.*,net.wotonomy.ui.*,net.wotonomy.util.*,net.wotonomy.web.*,net.wotonomy.xml.*" - windowtitle="wotonomy" - Overview="overview.html"> - <classpath> - <pathelement location="${project.dir.lib}/servlet.jar" /> - <pathelement location="${project.dir.lib}/xp.jar" /> - </classpath> - </javadoc> - </target> - - <!-- + <target name="docs" depends="javadoc" + description="Original doc generation target (deprecated)" /> + <target name="javadoc"> + <mkdir dir="docs" /> + <javadoc sourcepath="." destdir="${project.dir.javadoc}" + packagenames="net.wotonomy.control.*,net.wotonomy.foundation.*,net.wotonomy.ui.*,net.wotonomy.util.*,net.wotonomy.web.*,net.wotonomy.xml.*" + windowtitle="wotonomy" + Overview="overview.html"> + <classpath> + <pathelement location="${project.dir.lib}/servlet.jar" /> + <pathelement location="${project.dir.lib}/xp.jar" /> + </classpath> + </javadoc> + </target> + + <!-- Builds an executable jar file containing the license file, anything in the images directory, and everything in net/wotonomy, but excludes all .java source files. --> - <target name="library" depends="package" description="Original packaging target (deprecated)." /> - <target name="package" depends="compile-main"> - <property name="jar.filename.library" value="${project.dir.target}/${ant.project.name}-${project.version}.jar" /> - <delete failonerror="false" file="${jar.filename.library}" /> - <mkdir dir="${project.dir.target}" /> - <jar jarfile="${jar.filename.library}" basedir="${project.dir.resources}" - includes="license.txt" manifest="manifest.txt" /> - <jar update="true" jarfile="${jar.filename.library}" basedir="${project.dir.classes}" /> - </target> - - <target name="package-libraries" depends="compile-main"> - <jar jarfile="${package.jar.filename.prefix}_ui_components-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_ui_components-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/ui/swing/**/*.java" - excludes="net/wotonomy/ui/swing/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_datastore-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_datastore-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/datastore/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/foundation/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_control-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_control-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/control/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_ui-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_ui-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/ui/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/foundation/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_util-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_util-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/util/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_web-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_web-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/web/**/*.java" /> - - <jar jarfile="${package.jar.filename.prefix}_xml-${project.version}${package.jar.filename.suffix}" - basedir="${project.dir.resources}" includes="license.txt" /> - <jar jarfile="${package.jar.filename.prefix}_xml-${project.version}${package.jar.filename.suffix}" - update="true" basedir="${project.dir.classes}" includes="net/wotonomy/xml/**/*.java" /> -</target> - - <!-- + <target name="library" depends="package" + description="Original packaging target (deprecated)." /> + <target name="package" depends="compile-main"> + <property name="jar.filename.library" + value="${project.dir.target}/${ant.project.name}-${project.version}.jar" /> + <delete failonerror="false" file="${jar.filename.library}" /> + <mkdir dir="${project.dir.target}" /> + <jar jarfile="${jar.filename.library}" + basedir="${project.dir.resources}" + includes="license.txt" manifest="manifest.txt" /> + <jar update="true" jarfile="${jar.filename.library}" + basedir="${project.dir.classes}" /> + </target> + + <target name="package-libraries" depends="compile-main"> + <jar + jarfile="${package.jar.filename.prefix}_ui_components-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_ui_components-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/ui/swing/**/*.java" + excludes="net/wotonomy/ui/swing/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_datastore-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_datastore-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/datastore/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/foundation/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_control-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_control-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/control/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_ui-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_ui-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/ui/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_foundation-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/foundation/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_util-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_util-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/util/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_web-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_web-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/web/**/*.java" /> + + <jar + jarfile="${package.jar.filename.prefix}_xml-${project.version}${package.jar.filename.suffix}" + basedir="${project.dir.resources}" includes="license.txt" /> + <jar + jarfile="${package.jar.filename.prefix}_xml-${project.version}${package.jar.filename.suffix}" + update="true" basedir="${project.dir.classes}" + includes="net/wotonomy/xml/**/*.java" /> + </target> + + <!-- Deletes all class files in the wotonomy directories, and any recognized temp files. --> - <target name="clean"> - <delete dir="${project.dir.target}" includes="**/*"/> - </target> - - <target name="compile-test" depends="package"> - <javac destdir="${project.dir.classes}"> - <compilerarg value="-Xlint:unchecked" /> - <src path="${project.dir.src.test.java}" /> - <classpath> - <pathelement location="${project.dir.lib}/servlet.jar" /> - <pathelement location="${project.dir.lib}/xp.jar" /> - <pathelement location="${project.dir.lib}/xerces.jar" /> - <pathelement location="${project.dir.lib}/ognl.jar" /> - <pathelement location="${project.dir.lib}/junit.jar" /> - <pathelement location="${package.jar.filename}" /> - </classpath> - </javac> - </target> - - <target name="test" depends="package,compile-test"> - <echo message="TODO: Make junit tests work from ant." /> - <!-- - <junit fork="true" includeantruntime="true" haltonerror="true" haltonfailure="true" printsummary="true"> + <target name="clean"> + <delete dir="${project.dir.target}" includes="**/*" /> + </target> + + <target name="compile-test" depends="package"> + <javac destdir="${project.dir.classes}"> + <compilerarg value="-Xlint:unchecked" /> + <src path="${project.dir.src.test.java}" /> + <classpath> + <pathelement location="${project.dir.lib}/servlet.jar" /> + <pathelement location="${project.dir.lib}/xp.jar" /> + <pathelement location="${project.dir.lib}/xerces.jar" /> + <pathelement location="${project.dir.lib}/ognl.jar" /> + <pathelement location="${project.dir.lib}/junit.jar" /> + <pathelement location="${package.jar.filename}" /> + </classpath> + </javac> + </target> + + <target name="test" depends="package,compile-test"> + <echo message="TODO: Make junit tests work from ant." /> + <!-- + <junit fork="true" includeantruntime="true" haltonerror="true" + haltonfailure="true" printsummary="true"> <classpath> <pathelement path="${package.jar.filename}" /> <pathelement path="${project.dir.test-classes}" /> </classpath> </junit> --> - </target> + </target> - <target name="env" description="Display all properties"> + <target name="env" description="Display all properties"> - </target> + </target> </project> diff --git a/projects/net.wotonomy.all/src/site/resources/doc/ui-guide.html b/projects/net.wotonomy.all/src/site/resources/doc/ui-guide.html index 992eefa..124c62e 100644 --- a/projects/net.wotonomy.all/src/site/resources/doc/ui-guide.html +++ b/projects/net.wotonomy.all/src/site/resources/doc/ui-guide.html @@ -1,233 +1,337 @@ <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> + <head> -<title>wotonomy ui user guide</title> + <title>wotonomy ui user guide</title> <meta name="author" content=""> - <meta name="GENERATOR" content = "Almost Free Text v5.06; Copyright 1996-2000 Todd Coram. All rights reserved."> + <meta name="GENERATOR" content="Almost Free Text v5.06; Copyright 1996-2000 Todd Coram. All rights reserved."> </head> + <body> -<br><h1><a name="AFT-top"><center>wotonomy ui user guide</center></a></h1> -<!-- AFT Table of Contents (auto generated) --> -<ul> -<li> <a href="#Introduction">Introduction</a></li> -<ul> -<li> <a href="#Scope">Scope</a></li> -<li> <a href="#Overview">Overview</a></li> -<ul> -<li> <a href="#Where does it fit in?">Where does it fit in?</a></li> -<li> <a href="#A Typical MVC Java application">A Typical MVC Java application</a></li> -<li> <a href="#A Typical wotonomy Application">A Typical wotonomy Application</a></li> -<li> <a href="#Expanded Framework">Expanded Framework</a></li> -</ul> -</ul> -<li> <a href="#Using wotonomy">Using wotonomy</a></li> -<ul> -<li> <a href="#Designing Data Objects">Designing Data Objects</a></li> -<ul> -<li> <a href="#Java Bean Conventions">Java Bean Conventions</a></li> -<li> <a href="#Change Notification">Change Notification</a></li> -</ul> -<li> <a href="#Display Groups">Display Groups</a></li> -<ul> -<li> <a href="#Creating a Display Group">Creating a Display Group</a></li> -<li> <a href="#Populating a Display Group">Populating a Display Group</a></li> -<li> <a href="#Qualifying Displayed Objects">Qualifying Displayed Objects</a></li> -<li> <a href="#Handling Selection">Handling Selection</a></li> -<li> <a href="#Handling Insertions and Deletions">Handling Insertions and Deletions</a></li> -<li> <a href="#Delegate">Delegate</a></li> -</ul> -<li> <a href="#Associations">Associations</a></li> -<ul> -<li> <a href="#Creating Associations">Creating Associations</a></li> -<li> <a href="#Kinds of Associations">Kinds of Associations</a></li> -<li> <a href="#Master-Detail Associations">Master-Detail Associations</a></li> -<li> <a href="#Binding Aspects and Establishing Connections">Binding Aspects and Establishing Connections</a></li> -</ul> -<li> <a href="#Editing Contexts">Editing Contexts</a></li> -<ul> -<li> <a href="#Object Stores">Object Stores</a></li> -<li> <a href="#Creating an Editing Context">Creating an Editing Context</a></li> -</ul> -</ul> -<li> <a href="#What's next?">What's next?</a> + <br> + <h1><a name="AFT-top"> + <center>wotonomy ui user guide</center> + </a></h1> + <!-- AFT Table of Contents (auto generated) --> + <ul> + <li> <a href="#Introduction">Introduction</a></li> + <ul> + <li> <a href="#Scope">Scope</a></li> + <li> <a href="#Overview">Overview</a></li> + <ul> + <li> <a href="#Where does it fit in?">Where does it fit in?</a></li> + <li> <a href="#A Typical MVC Java application">A Typical MVC Java application</a></li> + <li> <a href="#A Typical wotonomy Application">A Typical wotonomy Application</a></li> + <li> <a href="#Expanded Framework">Expanded Framework</a></li> + </ul> + </ul> + <li> <a href="#Using wotonomy">Using wotonomy</a></li> + <ul> + <li> <a href="#Designing Data Objects">Designing Data Objects</a></li> + <ul> + <li> <a href="#Java Bean Conventions">Java Bean Conventions</a></li> + <li> <a href="#Change Notification">Change Notification</a></li> + </ul> + <li> <a href="#Display Groups">Display Groups</a></li> + <ul> + <li> <a href="#Creating a Display Group">Creating a Display Group</a></li> + <li> <a href="#Populating a Display Group">Populating a Display Group</a></li> + <li> <a href="#Qualifying Displayed Objects">Qualifying Displayed Objects</a></li> + <li> <a href="#Handling Selection">Handling Selection</a></li> + <li> <a href="#Handling Insertions and Deletions">Handling Insertions and Deletions</a></li> + <li> <a href="#Delegate">Delegate</a></li> + </ul> + <li> <a href="#Associations">Associations</a></li> + <ul> + <li> <a href="#Creating Associations">Creating Associations</a></li> + <li> <a href="#Kinds of Associations">Kinds of Associations</a></li> + <li> <a href="#Master-Detail Associations">Master-Detail Associations</a></li> + <li> <a href="#Binding Aspects and Establishing Connections">Binding Aspects and Establishing + Connections</a></li> + </ul> + <li> <a href="#Editing Contexts">Editing Contexts</a></li> + <ul> + <li> <a href="#Object Stores">Object Stores</a></li> + <li> <a href="#Creating an Editing Context">Creating an Editing Context</a></li> + </ul> + </ul> + <li> <a href="#What's next?">What's next?</a> -</li> -</ul> -<h2><a name="Introduction">Introduction</a></h2> -<h3><a name="Scope">Scope</a></h3> -<p> -This document is intended to serve as a Java developer's introduction to the wotonomy user interface framework and how to use it to build a graphical user interface application with Swing. -</p> -<!--End Section h3--> -<h3><a name="Overview">Overview</a></h3> -<p> -The wotonomy user interface package contained in net.wotonomy.ui provides a design pattern that further abstracts and decouples the model, view, and controller portions of a graphical user interface application. It lets you do more with less code. -</p> -<h4><a name="Where does it fit in?">Where does it fit in?</a></h4> -<p> -Let's begin by looking at the standard model-view-controller (MVC) architecture, and then we'll look at how the design changes with wotonomy. -</p> -<!--End Section h4--> -<h4><a name="A Typical MVC Java application">A Typical MVC Java application</a></h4> -<p> -A typical Java application can be described in a very high-level way as simply reading a bunch of data objects into memory from the file system or JDBC or elsewhere and rendering a graphical representation of the data for the user. Additionally, the user may be allowed to edit some or all the data represented, and in that case the modifications are copied back from whence they were read. -</p> -<img src="images/standard-mvc.gif" alt="" align=bottom> -<p> -In MVC parlance, the model is an object-oriented representation of your data and business logic. In the typical application example, the data objects are the model. To afford maximum reuse, these data objects have no knowledge of and no dependencies on the view or controller portions of your application. In the Enterprise Java Bean (EJB) world, entity beans are usually good examples of data objects. -</p> -<p> -The view is the user interface of your application, where the data objects are represented on screen using labels, text fields, sliders, and the like. While you might need to know a little bit about the data you are trying to visualize when constructing the user interface, the view classes have no code dependencies on the data object classes in the model. And the view similarly has no code dependencies on the controller. To afford maximum flexibility, the view consists only of the Swing components arranged in the proper layouts and nothing more. -</p> -<p> -The controller, on the other hand, contains the logic specific to the Java Swing application you are writing, and it is tightly coupled with and has deep code dependencies on the model and view. -</p> -<p> -The controller is responsible for fetching the data objects that will be viewed or edited, and is responsible for populating each user interface component in the view with data from the data objects. This means that the controller directly calls methods on both the model's data objects and the view's user interface components. -</p> -<p> -If the application supports editing, the controller is responsible for even more. It must detect changes to the view, like edited text fields or moved sliders, and update the model to reflect the changes. And it must detect changes in the model and update the view components accordingly (especially for side-effect changes like a task's status changing in the data model when the user assigns a worker). These responsibilities deepen the couplings with both the model and the view. -</p> -<p> -Furthermore, the controller must track commits and reverts of sets of changes to the data model, and it must track lists of edited, added, and deleted objects to efficiently update the persistent data store. And these responsibilities deepen the complexity of the logic contained in the controller. -</p> -<!--End Section h4--> -<h4><a name="A Typical wotonomy Application">A Typical wotonomy Application</a></h4> -<p> -Because so much code resides in the controller portion of an application, and because the controller is the least generic and therefore least reusable code in an application, wotonomy is designed to abstract and simplify the responsibilities of the controller to reduce the cost of writing and maintaining it. -</p> -<img src="images/wotonomy-mvc.gif" alt="" align=bottom> -<p> -With wotonomy, the only requirement on the model portion of your application is that the data objects adhere to Java Bean naming conventions for properties. Wotonomy further decouples your model from the rest of your application by working with it only through the use of bean properties. -</p> -<p> -The view portion of your application remains the same. The controller portion, however, is vastly simplified. -</p> -<p> -The fetched data objects are placed into an EditingContext. The editing context monitors the objects for changes, and tracks insertions and deletions, and handles commits and reverts. The controller is only responsible for providing the glue to allow the editing context to talk to whatever persistent object storage is used for the application. If your data is read only or if your data model is fairly simple, then the editing context can be omitted and your job is even easier. -</p> -<p> -A DisplayGroup then retrieves some or all of those objects from the EditingContext. A display group maintains an ordered collection of objects, monitoring them for changes. The display group additionally tracks the concept of selection: a subset of objects in the display group are selected, and the selection might contain zero, one, many, or all objects in the group. The display group broadcasts notifications of changes to the data object or to the selection to interested listeners. The controller is only responsible for creating the display group and deciding what objects from the editing context should be placed in the group. -</p> -<p> -An Association is then created for each user interface component in the view. Each association is bound to the display group as a listener for change notifications. Different types of associations correspond to different kinds of user interface objects: a JTextField with a TextAssociation will display the value of a property for the selected object in the bound display group, while a TableColumn with a TableColumnAssociation will display the value of a property for all objects in the bound display group, highlighting those objects that are selected. The controller is only responsible for creating the associations, connecting them to the user interface components, and binding them to the display group. -</p> -<p> -Your controller will not need to directly touch any data objects, and will only need to access the view to get references to the user interface components and pass them on to the associations. After all the pieces are connected, they'll just work and it's pretty much fire and forget. -</p> -<!--End Section h4--> -<h4><a name="Expanded Framework">Expanded Framework</a></h4> -<p> -On the whole, an application may have one or more editing contexts, each of which may be used by one or more display groups, each of which is observed by one or more associations, each of which is connected to a single user interface component. But there's a little more to this story. -</p> -<img src="images/wotonomy-er.gif" alt="" align=bottom> -<p> -As the diagram shows, a display group actually has a data source which has an editing context, and editing contexts have object stores which can in turn be editing contexts. This means that editing contexts can be nested within one another. And there are associations that can control a display group instead of a Swing component, which means that display groups can also be nested. -</p> -<p> -However, you can write a fully-functional application using just display groups and associations, skipping the editing contexts and data sources completely. -</p> -<p> -Wotonomy makes the simple things easy while still making complex things possible. -</p> -<!--End Section h4--> -<!--End Section h3--> -<!--End Section h2--> -<h2><a name="Using wotonomy">Using wotonomy</a></h2> -<p> -Wotonomy is a design pattern as well as a Java library, so you'll want to understand how to structure your application to best leverage the framework. -</p> -<h3><a name="Designing Data Objects">Designing Data Objects</a></h3> -<p> -In short, any objects that have getter and setter methods can be used in a display group. Your objects probably have those already. Even better are objects that use Java Bean naming conventions to define properties. You probably do that too. For change notifications, extending java.util.Observable is helpful, but since your objects probably don't already do that, there is an alternate way to post change notifications. Or you can choose to not post notifications at all. The requirements of wotonomy on your data model are minimal. -</p> -<h4><a name="Java Bean Conventions">Java Bean Conventions</a></h4> -<p> -A java bean property is defined by having a method of the form getProperty() where Property is the name of the property, for example, a name property is defined by the method getName(). The get method can have no parameters and the return type defines the type of the property. (The alternate form for getters that omits the get in the method name, e.g. property(), is also supported.) -</p> -<p> -An editable property is defined by additionally having a method of the form setProperty( Object aProperty ) where the return value is void and the type of the parameter matches the type of the getter method. (When a property has a getter method but no setter method, that property is considered-read only.) -</p> -<p> -An indexed property works the same way but the type is either an Array (like Object[] or String[]) or a Collection (like Set or List). Indexed properties typically define one-to-many relationships in your data model. Indexed properties are useful for nested display groups and recursive tree associations. -</p> -<!--End Section h4--> -<h4><a name="Change Notification">Change Notification</a></h4> -<p> -The Java way for objects to post change notifications is to extend java.util.Observable and call notifyObservers() after your change has taken place. If your data object extends Observable, DisplayGroups will register themselves as observers and expect notifications for changes that occur to the object, whether from user interaction or from external influence. -</p> -<p> -The Observable approach may be undesirable if you need to subclass a third party object that does not extend Observable or if you don't want a strong reference to an observer from your data object that may need to be manually cleared later. -</p> -<p> -For objects that do not extend Observer, you can get much the same effect by calling the static method <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObserverCenter.html#notifyObserversObjectWillChange">EOObserverCenter.notifyObserversObjectWillChange()</a> before your change takes place. -</p> -<p> -Wotonomy uses <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObserverCenter.html">EOObserverCenter</a> exclusively within the framework and it presents a preferrable alternative to Observable because it uses weak references to track objects and it relaxes the requirement that observed objects extend a particular class by requiring that observing objects implement the EOObserving interface. The EOObserverCenter can also coalesce change events if the observing object extends <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EODelayedObserver.html">EODelayedObserver</a>. -</p> -<p> -Please note that if your object does not post change notifications, most of wotonomy will continue to work. The only problem will then be that changes external to wotonomy - changes made to your data model by your data model or by a timed refresh or something similar - will not be automatically reflected in the user interface. Manually calling <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.html#updateDisplayedObjects">EODisplayGroup.updateDisplayedObjects()</a> can refresh the display. -</p> -<!--End Section h4--> -<!--End Section h3--> -<h3><a name="Display Groups">Display Groups</a></h3> -<p> -<a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.html">Display groups</a> are objects that manage an ordered list of data objects. Of this list, a subset are considered to be "displayed" objects that are visible to the user. Of the displayed objects, a subset are considered "selected". In common usage, all of the objects are displayed, but only one object and sometimes no objects are selected. -</p> -<p> -Display groups monitor changes to the list, changes to what objects are in the list, changes to which objects are selected, as well as changes to the properties of the objects themselves, and notify any bound associations of these changes. -</p> -<p> -If the display group has a delegate, the delegate is informed of these changes and more so that the delegate can fine-tune the behavior of the display group. -</p> -<h4><a name="Creating a Display Group">Creating a Display Group</a></h4> -<p> -A display group is created very simply with the default constructor. -This creates a display group with no data source, no delegate, and no objects to manage. -</p> -<pre> + </li> + </ul> + <h2><a name="Introduction">Introduction</a></h2> + <h3><a name="Scope">Scope</a></h3> + <p> + This document is intended to serve as a Java developer's introduction to the wotonomy user interface framework + and how to use it to build a graphical user interface application with Swing. + </p> + <!--End Section h3--> + <h3><a name="Overview">Overview</a></h3> + <p> + The wotonomy user interface package contained in net.wotonomy.ui provides a design pattern that further + abstracts and decouples the model, view, and controller portions of a graphical user interface application. It + lets you do more with less code. + </p> + <h4><a name="Where does it fit in?">Where does it fit in?</a></h4> + <p> + Let's begin by looking at the standard model-view-controller (MVC) architecture, and then we'll look at how the + design changes with wotonomy. + </p> + <!--End Section h4--> + <h4><a name="A Typical MVC Java application">A Typical MVC Java application</a></h4> + <p> + A typical Java application can be described in a very high-level way as simply reading a bunch of data objects + into memory from the file system or JDBC or elsewhere and rendering a graphical representation of the data for + the user. Additionally, the user may be allowed to edit some or all the data represented, and in that case the + modifications are copied back from whence they were read. + </p> + <img src="images/standard-mvc.gif" alt="" align=bottom> + <p> + In MVC parlance, the model is an object-oriented representation of your data and business logic. In the typical + application example, the data objects are the model. To afford maximum reuse, these data objects have no + knowledge of and no dependencies on the view or controller portions of your application. In the Enterprise Java + Bean (EJB) world, entity beans are usually good examples of data objects. + </p> + <p> + The view is the user interface of your application, where the data objects are represented on screen using + labels, text fields, sliders, and the like. While you might need to know a little bit about the data you are + trying to visualize when constructing the user interface, the view classes have no code dependencies on the data + object classes in the model. And the view similarly has no code dependencies on the controller. To afford + maximum flexibility, the view consists only of the Swing components arranged in the proper layouts and nothing + more. + </p> + <p> + The controller, on the other hand, contains the logic specific to the Java Swing application you are writing, + and it is tightly coupled with and has deep code dependencies on the model and view. + </p> + <p> + The controller is responsible for fetching the data objects that will be viewed or edited, and is responsible + for populating each user interface component in the view with data from the data objects. This means that the + controller directly calls methods on both the model's data objects and the view's user interface components. + </p> + <p> + If the application supports editing, the controller is responsible for even more. It must detect changes to the + view, like edited text fields or moved sliders, and update the model to reflect the changes. And it must detect + changes in the model and update the view components accordingly (especially for side-effect changes like a + task's status changing in the data model when the user assigns a worker). These responsibilities deepen the + couplings with both the model and the view. + </p> + <p> + Furthermore, the controller must track commits and reverts of sets of changes to the data model, and it must + track lists of edited, added, and deleted objects to efficiently update the persistent data store. And these + responsibilities deepen the complexity of the logic contained in the controller. + </p> + <!--End Section h4--> + <h4><a name="A Typical wotonomy Application">A Typical wotonomy Application</a></h4> + <p> + Because so much code resides in the controller portion of an application, and because the controller is the + least generic and therefore least reusable code in an application, wotonomy is designed to abstract and simplify + the responsibilities of the controller to reduce the cost of writing and maintaining it. + </p> + <img src="images/wotonomy-mvc.gif" alt="" align=bottom> + <p> + With wotonomy, the only requirement on the model portion of your application is that the data objects adhere to + Java Bean naming conventions for properties. Wotonomy further decouples your model from the rest of your + application by working with it only through the use of bean properties. + </p> + <p> + The view portion of your application remains the same. The controller portion, however, is vastly simplified. + </p> + <p> + The fetched data objects are placed into an EditingContext. The editing context monitors the objects for + changes, and tracks insertions and deletions, and handles commits and reverts. The controller is only + responsible for providing the glue to allow the editing context to talk to whatever persistent object storage is + used for the application. If your data is read only or if your data model is fairly simple, then the editing + context can be omitted and your job is even easier. + </p> + <p> + A DisplayGroup then retrieves some or all of those objects from the EditingContext. A display group maintains an + ordered collection of objects, monitoring them for changes. The display group additionally tracks the concept of + selection: a subset of objects in the display group are selected, and the selection might contain zero, one, + many, or all objects in the group. The display group broadcasts notifications of changes to the data object or + to the selection to interested listeners. The controller is only responsible for creating the display group and + deciding what objects from the editing context should be placed in the group. + </p> + <p> + An Association is then created for each user interface component in the view. Each association is bound to the + display group as a listener for change notifications. Different types of associations correspond to different + kinds of user interface objects: a JTextField with a TextAssociation will display the value of a property for + the selected object in the bound display group, while a TableColumn with a TableColumnAssociation will display + the value of a property for all objects in the bound display group, highlighting those objects that are + selected. The controller is only responsible for creating the associations, connecting them to the user + interface components, and binding them to the display group. + </p> + <p> + Your controller will not need to directly touch any data objects, and will only need to access the view to get + references to the user interface components and pass them on to the associations. After all the pieces are + connected, they'll just work and it's pretty much fire and forget. + </p> + <!--End Section h4--> + <h4><a name="Expanded Framework">Expanded Framework</a></h4> + <p> + On the whole, an application may have one or more editing contexts, each of which may be used by one or more + display groups, each of which is observed by one or more associations, each of which is connected to a single + user interface component. But there's a little more to this story. + </p> + <img src="images/wotonomy-er.gif" alt="" align=bottom> + <p> + As the diagram shows, a display group actually has a data source which has an editing context, and editing + contexts have object stores which can in turn be editing contexts. This means that editing contexts can be + nested within one another. And there are associations that can control a display group instead of a Swing + component, which means that display groups can also be nested. + </p> + <p> + However, you can write a fully-functional application using just display groups and associations, skipping the + editing contexts and data sources completely. + </p> + <p> + Wotonomy makes the simple things easy while still making complex things possible. + </p> + <!--End Section h4--> + <!--End Section h3--> + <!--End Section h2--> + <h2><a name="Using wotonomy">Using wotonomy</a></h2> + <p> + Wotonomy is a design pattern as well as a Java library, so you'll want to understand how to structure your + application to best leverage the framework. + </p> + <h3><a name="Designing Data Objects">Designing Data Objects</a></h3> + <p> + In short, any objects that have getter and setter methods can be used in a display group. Your objects probably + have those already. Even better are objects that use Java Bean naming conventions to define properties. You + probably do that too. For change notifications, extending java.util.Observable is helpful, but since your + objects probably don't already do that, there is an alternate way to post change notifications. Or you can + choose to not post notifications at all. The requirements of wotonomy on your data model are minimal. + </p> + <h4><a name="Java Bean Conventions">Java Bean Conventions</a></h4> + <p> + A java bean property is defined by having a method of the form getProperty() where Property is the name of the + property, for example, a name property is defined by the method getName(). The get method can have no parameters + and the return type defines the type of the property. (The alternate form for getters that omits the get in the + method name, e.g. property(), is also supported.) + </p> + <p> + An editable property is defined by additionally having a method of the form setProperty( Object aProperty ) + where the return value is void and the type of the parameter matches the type of the getter method. (When a + property has a getter method but no setter method, that property is considered-read only.) + </p> + <p> + An indexed property works the same way but the type is either an Array (like Object[] or String[]) or a + Collection (like Set or List). Indexed properties typically define one-to-many relationships in your data model. + Indexed properties are useful for nested display groups and recursive tree associations. + </p> + <!--End Section h4--> + <h4><a name="Change Notification">Change Notification</a></h4> + <p> + The Java way for objects to post change notifications is to extend java.util.Observable and call + notifyObservers() after your change has taken place. If your data object extends Observable, DisplayGroups will + register themselves as observers and expect notifications for changes that occur to the object, whether from + user interaction or from external influence. + </p> + <p> + The Observable approach may be undesirable if you need to subclass a third party object that does not extend + Observable or if you don't want a strong reference to an observer from your data object that may need to be + manually cleared later. + </p> + <p> + For objects that do not extend Observer, you can get much the same effect by calling the static method <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObserverCenter.html#notifyObserversObjectWillChange">EOObserverCenter.notifyObserversObjectWillChange()</a> + before your change takes place. + </p> + <p> + Wotonomy uses <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObserverCenter.html">EOObserverCenter</a> + exclusively within the framework and it presents a preferrable alternative to Observable because it uses weak + references to track objects and it relaxes the requirement that observed objects extend a particular class by + requiring that observing objects implement the EOObserving interface. The EOObserverCenter can also coalesce + change events if the observing object extends <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EODelayedObserver.html">EODelayedObserver</a>. + </p> + <p> + Please note that if your object does not post change notifications, most of wotonomy will continue to work. The + only problem will then be that changes external to wotonomy - changes made to your data model by your data model + or by a timed refresh or something similar - will not be automatically reflected in the user interface. Manually + calling <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.html#updateDisplayedObjects">EODisplayGroup.updateDisplayedObjects()</a> + can refresh the display. + </p> + <!--End Section h4--> + <!--End Section h3--> + <h3><a name="Display Groups">Display Groups</a></h3> + <p> + <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.html">Display groups</a> are + objects that manage an ordered list of data objects. Of this list, a subset are considered to be + "displayed" objects that are visible to the user. Of the displayed objects, a subset are considered + "selected". In common usage, all of the objects are displayed, but only one object and sometimes no + objects are selected. + </p> + <p> + Display groups monitor changes to the list, changes to what objects are in the list, changes to which objects + are selected, as well as changes to the properties of the objects themselves, and notify any bound associations + of these changes. + </p> + <p> + If the display group has a delegate, the delegate is informed of these changes and more so that the delegate can + fine-tune the behavior of the display group. + </p> + <h4><a name="Creating a Display Group">Creating a Display Group</a></h4> + <p> + A display group is created very simply with the default constructor. + This creates a display group with no data source, no delegate, and no objects to manage. + </p> + <pre> EODisplayGroup displayGroup = new EODisplayGroup(); </pre> -<!--End Section h4--> -<h4><a name="Populating a Display Group">Populating a Display Group</a></h4> -<p> -You can populate the display group with objects in two ways. -</p> -<p> -The direct way is easiest. Simply pass in a List containing the objects to be managed in the order they should appear. -</p> -<pre> + <!--End Section h4--> + <h4><a name="Populating a Display Group">Populating a Display Group</a></h4> + <p> + You can populate the display group with objects in two ways. + </p> + <p> + The direct way is easiest. Simply pass in a List containing the objects to be managed in the order they should + appear. + </p> + <pre> List objectList = new LinkedList(); objectList.add( new TestObject() ); displayGroup.setObjectArray( objectList ); </pre> -<p> -Alternately, you can specify a data source for the display group to use to retrieve objects. -</p> -<p> -<a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EODataSource.html">EODataSource</a> is an abstract class that you will extend with methods to create, insert, and delete objects from whatever persistent object store you are using. This class is particularly useful for rendering recursive tree-like object relationships that the data objects do not explicitly model. -</p> -<p> -If you will be using an editing context, you will need to use a data source. -</p> -<pre> + <p> + Alternately, you can specify a data source for the display group to use to retrieve objects. + </p> + <p> + <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EODataSource.html">EODataSource</a> is an + abstract class that you will extend with methods to create, insert, and delete objects from whatever persistent + object store you are using. This class is particularly useful for rendering recursive tree-like object + relationships that the data objects do not explicitly model. + </p> + <p> + If you will be using an editing context, you will need to use a data source. + </p> + <pre> EODataSource dataSource = new MyDataSource(); displayGroup.setDataSource( dataSource ); displayGroup.fetch(); </pre> -<!--End Section h4--> -<h4><a name="Qualifying Displayed Objects">Qualifying Displayed Objects</a></h4> -<p> -The displayed objects are a subset of the list of objects that the display group manages. By default all objects are displayed. -</p> -<p> -You can change this behavior by specifying a qualifier for the display group. This is an instance of <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOQualifier.html">EOQualifier</a> and it will have evaluateWithObject called for every object in the display group. Only those objects for which the return value is true will be in the displayed objects list. Call updateDisplayedObjects() on the display group to apply the qualifier. -</p> -<p> -You would typically use this feature when you want to preload a large number of data objects into the display group so that the user can quickly and repeatedly apply different filters to sift through the data. -</p> -<pre> + <!--End Section h4--> + <h4><a name="Qualifying Displayed Objects">Qualifying Displayed Objects</a></h4> + <p> + The displayed objects are a subset of the list of objects that the display group manages. By default all objects + are displayed. + </p> + <p> + You can change this behavior by specifying a qualifier for the display group. This is an instance of <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOQualifier.html">EOQualifier</a> and it + will have evaluateWithObject called for every object in the display group. Only those objects for which the + return value is true will be in the displayed objects list. Call updateDisplayedObjects() on the display group + to apply the qualifier. + </p> + <p> + You would typically use this feature when you want to preload a large number of data objects into the display + group so that the user can quickly and repeatedly apply different filters to sift through the data. + </p> + <pre> // show only Powers in San Antonio Map matchValues = new HashMap(); @@ -239,15 +343,18 @@ You would typically use this feature when you want to preload a large number of displayGroup.setQualifier( qualifier ); displayGroup.updateDisplayedObjects(); </pre> -<!--End Section h4--> -<h4><a name="Handling Selection">Handling Selection</a></h4> -<p> -Display groups also track which of the displayed objects are selected. By default no objects are selected, but you can change the selection programmatically. Certain associations allow the user to change the selection as well. -</p> -<p> -If you do not provide the user with an association that can change the selection, you should make sure to set the selection to some object. -</p> -<pre> + <!--End Section h4--> + <h4><a name="Handling Selection">Handling Selection</a></h4> + <p> + Display groups also track which of the displayed objects are selected. By default no objects are selected, but + you can change the selection programmatically. Certain associations allow the user to change the selection as + well. + </p> + <p> + If you do not provide the user with an association that can change the selection, you should make sure to set + the selection to some object. + </p> + <pre> // select all objects displayGroup.setSelectedObjects( displayGroup.displayedObjects() ); @@ -263,21 +370,26 @@ If you do not provide the user with an association that can change the selection // clear the selection displayGroup.clearSelection(); </pre> -<!--End Section h4--> -<h4><a name="Handling Insertions and Deletions">Handling Insertions and Deletions</a></h4> -<p> -You can programmatically insert or delete objects from a display group, although only if they are displayed. Any associations that display all of the displayed objects (like TableColumns) will be updated automatically. -</p> -<p> -Deleted objects that were selected are removed from the selection. Inserted objects are not selected, so you will need to select them manually if desired. Default values for inserted objects can be specified with setInsertedObjectDefaultValues(). -</p> -<p> -If a data source is used, the data source will be informed of the insertion or deletion, which will notify the editing context if it has one, which would update the persistent store on commit. -</p> -<p> -Also, if a data source is used, the display group can be asked to simply create an object to be inserted into the group, which will call createObject() on the data source. -</p> -<pre> + <!--End Section h4--> + <h4><a name="Handling Insertions and Deletions">Handling Insertions and Deletions</a></h4> + <p> + You can programmatically insert or delete objects from a display group, although only if they are displayed. Any + associations that display all of the displayed objects (like TableColumns) will be updated automatically. + </p> + <p> + Deleted objects that were selected are removed from the selection. Inserted objects are not selected, so you + will need to select them manually if desired. Default values for inserted objects can be specified with + setInsertedObjectDefaultValues(). + </p> + <p> + If a data source is used, the data source will be informed of the insertion or deletion, which will notify the + editing context if it has one, which would update the persistent store on commit. + </p> + <p> + Also, if a data source is used, the display group can be asked to simply create an object to be inserted into + the group, which will call createObject() on the data source. + </p> + <pre> // insert an object displayGroup.insertObjectAtIndex( new TestObject(), 0 ); @@ -293,86 +405,141 @@ Also, if a data source is used, the display group can be asked to simply create // insert a new object displayGroup.insertNewObjectAtIndex( 0 ); </pre> -<!--End Section h4--> -<h4><a name="Delegate">Delegate</a></h4> -<p> -Display groups check with their delegate before performing almost any operation, you can easily customize the behavior of a display group by providing a class that implements the <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.Delegate.html">DisplayGroup.Delegate</a> interface. -</p> -<p> -Display groups ask their delegate for permission to fetch, insert, delete, edit, create, and change selection, and then notify their delegate after each of these operations has taken place. Wotonomy provides a DelegateAdapter class that you can easily subclass to implement the required interface. -</p> -<!--End Section h4--> -<!--End Section h3--> -<h3><a name="Associations">Associations</a></h3> -<p> -<a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EOAssociation.html">Associations</a> are the bridge between the controller and the view. An association has exactly one "controlled object", which is usually a user interface component. They also have one or sometimes more "aspects", each of which has a name, like ValueAspect or EnabledAspect. -You bind an aspect of an association with a display group and/or a key. Then you establish the connection between the association and the controlled object and you're done and you can forget about it. The association will keep the user interface object synchronized with the objects in the display group. -</p> -<h4><a name="Creating Associations">Creating Associations</a></h4> -<p> -You create an association by calling the constructor of the subclass of EOAssociation that is appropriate for the controlled object. Most associations are applicable to many kinds of objects, so the constructor is expected to take an Object. (This means that if you specify the wrong kind of object for the association, you won't hear about it until runtime.) -</p> -<pre> + <!--End Section h4--> + <h4><a name="Delegate">Delegate</a></h4> + <p> + Display groups check with their delegate before performing almost any operation, you can easily customize the + behavior of a display group by providing a class that implements the <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EODisplayGroup.Delegate.html">DisplayGroup.Delegate</a> + interface. + </p> + <p> + Display groups ask their delegate for permission to fetch, insert, delete, edit, create, and change selection, + and then notify their delegate after each of these operations has taken place. Wotonomy provides a + DelegateAdapter class that you can easily subclass to implement the required interface. + </p> + <!--End Section h4--> + <!--End Section h3--> + <h3><a name="Associations">Associations</a></h3> + <p> + <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/EOAssociation.html">Associations</a> are the + bridge between the controller and the view. An association has exactly one "controlled object", which + is usually a user interface component. They also have one or sometimes more "aspects", each of which + has a name, like ValueAspect or EnabledAspect. + You bind an aspect of an association with a display group and/or a key. Then you establish the connection + between the association and the controlled object and you're done and you can forget about it. The association + will keep the user interface object synchronized with the objects in the display group. + </p> + <h4><a name="Creating Associations">Creating Associations</a></h4> + <p> + You create an association by calling the constructor of the subclass of EOAssociation that is appropriate for + the controlled object. Most associations are applicable to many kinds of objects, so the constructor is expected + to take an Object. (This means that if you specify the wrong kind of object for the association, you won't hear + about it until runtime.) + </p> + <pre> EOAssociation association = new TextAssociation( textField ); </pre> -<!--End Section h4--> -<h4><a name="Kinds of Associations">Kinds of Associations</a></h4> -<p> -Associations fall into one of two categories: overview associations and detail associations. Almost all associations are used to control some kind of user interface component. -</p> -<p> -Overview associations show some property of all the items in the display group. Overview associations usually allow the user to select and deselect objects in the display group. -</p> -<p> -For example, a JList might be used with a <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/ListAssociation.html">ListAssociation</a> to show the "name" property of all of the displayed objects in the display group, in the same order. Clicking the fourth name in the list would cause the fourth object in the display group to be selected, and - depending on the JList's selection model - cause whatever was previously selected to become unselected. -</p> -<p> -Detail associations show some property of only the first selected object in the display group. If there is no selection, the detail association causes the controlled component to be blank or otherwise empty. If multiple objects are selected, the detail association shows the property of only the first object in the selected objects list. -</p> -<p> -In our example, a JTextField might be used with a <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TextAssociation.html">TextAssociation</a> to display the "email" property of the selected item in the display group. Clicking the fourth name in the list causes the fourth item in the display group to be selected, which populates the text field with the value of the email property for that object. Changing the value in the text field changes the value of that object's email property automatically. -</p> -<!--End Section h4--> -<h4><a name="Master-Detail Associations">Master-Detail Associations</a></h4> -<p> -While nearly all associations control user interface components, the <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/MasterDetailAssociation.html">MasterDetailAssociation</a> is worthy of note because it does not. -</p> -<p> -A MasterDetailAssociation controls a display group and binds to an indexed property of the objects in another display group. It is a detail association, with the bound display group as the "master" and the controlled display group as the "detail" component. -</p> -<p> -Again using our example, another JList might be used with a ListAssociation to show all the dependents of the person selected in the first JList. -</p> -<p> -First we would create a new display group and then create a MasterDetailAssociation with our new display group as the parameter to the constructor. Then we would bind that association to our original master display group with the "dependents" property (assuming there is a method on our data object called getDependents() that returns an array or a collection of objects). Then we would create our new ListAssociation controlling our new JList, and bind that to our new display group with the "name" property. Seeing the source might make this clearer - that's coming in the next section. -</p> -<p> -Clicking on a name in the name list would then display the email address in the text field and a list of names of all the dependents. -</p> -<!--End Section h4--> -<h4><a name="Binding Aspects and Establishing Connections">Binding Aspects and Establishing Connections</a></h4> -<p> -An association has one or more aspects. Most of the time, you'll just need one aspect, sometimes called the "primary aspect". Aspects are referred to by name, like ValueAspect, and the names of an association's aspects are static members of that association's class. -</p> -<p> -The primary aspect is usually responsible for populating the controlled object with data from the display group. The other aspects are useful, but they'll do different things depending on the nature of the association, so you should consult the documentation for the association you will be using. -</p> -<p> -To bind an aspect, you call bindAspect() with the name of the aspect, a display group and a string "key". -</p> -<p> -Usually, all three are specified, and the key is a property name. The association will display or edit the value of this property for the objects in the display group. -</p> -<p> -The key may be an empty string, and this is considered the "identity property", and the value of the actual object in the display group will be used instead of a property on that object. This is sometimes useful for view components like JTrees for which you want to write custom renderers: with the identity property, the renderer receives the value of the actual object. -</p> -<p> -The display group may be left null, in which case the key is treated as a value, acting as if all objects in the display group for the given property returned that value. This is useful for certain aspects of certain associations, like the EnabledAspect of <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TextAssociation.html">TextAssociation</a>, or the EditableAspect of <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TableColumnAssociation.html">TableColumnAssociation</a>. -</p> -<p> -After all the aspects have been bound, you need to call establishConnection() to put the association to work. Importantly, you do not need to retain a reference to the associations you create - they will exist as long as their controlled components exist, and when the controlled component is garbage collected, the association will be garbage collected. -</p> -<pre> + <!--End Section h4--> + <h4><a name="Kinds of Associations">Kinds of Associations</a></h4> + <p> + Associations fall into one of two categories: overview associations and detail associations. Almost all + associations are used to control some kind of user interface component. + </p> + <p> + Overview associations show some property of all the items in the display group. Overview associations usually + allow the user to select and deselect objects in the display group. + </p> + <p> + For example, a JList might be used with a <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/ListAssociation.html">ListAssociation</a> + to show the "name" property of all of the displayed objects in the display group, in the same order. + Clicking the fourth name in the list would cause the fourth object in the display group to be selected, and - + depending on the JList's selection model - cause whatever was previously selected to become unselected. + </p> + <p> + Detail associations show some property of only the first selected object in the display group. If there is no + selection, the detail association causes the controlled component to be blank or otherwise empty. If multiple + objects are selected, the detail association shows the property of only the first object in the selected objects + list. + </p> + <p> + In our example, a JTextField might be used with a <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TextAssociation.html">TextAssociation</a> + to display the "email" property of the selected item in the display group. Clicking the fourth name in + the list causes the fourth item in the display group to be selected, which populates the text field with the + value of the email property for that object. Changing the value in the text field changes the value of that + object's email property automatically. + </p> + <!--End Section h4--> + <h4><a name="Master-Detail Associations">Master-Detail Associations</a></h4> + <p> + While nearly all associations control user interface components, the <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/MasterDetailAssociation.html">MasterDetailAssociation</a> + is worthy of note because it does not. + </p> + <p> + A MasterDetailAssociation controls a display group and binds to an indexed property of the objects in another + display group. It is a detail association, with the bound display group as the "master" and the + controlled display group as the "detail" component. + </p> + <p> + Again using our example, another JList might be used with a ListAssociation to show all the dependents of the + person selected in the first JList. + </p> + <p> + First we would create a new display group and then create a MasterDetailAssociation with our new display group + as the parameter to the constructor. Then we would bind that association to our original master display group + with the "dependents" property (assuming there is a method on our data object called getDependents() + that returns an array or a collection of objects). Then we would create our new ListAssociation controlling our + new JList, and bind that to our new display group with the "name" property. Seeing the source might + make this clearer - that's coming in the next section. + </p> + <p> + Clicking on a name in the name list would then display the email address in the text field and a list of names + of all the dependents. + </p> + <!--End Section h4--> + <h4><a name="Binding Aspects and Establishing Connections">Binding Aspects and Establishing Connections</a></h4> + <p> + An association has one or more aspects. Most of the time, you'll just need one aspect, sometimes called the + "primary aspect". Aspects are referred to by name, like ValueAspect, and the names of an association's + aspects are static members of that association's class. + </p> + <p> + The primary aspect is usually responsible for populating the controlled object with data from the display group. + The other aspects are useful, but they'll do different things depending on the nature of the association, so you + should consult the documentation for the association you will be using. + </p> + <p> + To bind an aspect, you call bindAspect() with the name of the aspect, a display group and a string + "key". + </p> + <p> + Usually, all three are specified, and the key is a property name. The association will display or edit the value + of this property for the objects in the display group. + </p> + <p> + The key may be an empty string, and this is considered the "identity property", and the value of the + actual object in the display group will be used instead of a property on that object. This is sometimes useful + for view components like JTrees for which you want to write custom renderers: with the identity property, the + renderer receives the value of the actual object. + </p> + <p> + The display group may be left null, in which case the key is treated as a value, acting as if all objects in the + display group for the given property returned that value. This is useful for certain aspects of certain + associations, like the EnabledAspect of <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TextAssociation.html">TextAssociation</a>, + or the EditableAspect of <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/ui/swing/TableColumnAssociation.html">TableColumnAssociation</a>. + </p> + <p> + After all the aspects have been bound, you need to call establishConnection() to put the association to work. + Importantly, you do not need to retain a reference to the associations you create - they will exist as long as + their controlled components exist, and when the controlled component is garbage collected, the association will + be garbage collected. + </p> + <pre> // set up the master display group EODisplayGroup masterGroup = new EODisplayGroup(); masterGroup.setObjectArray( getMyUsers() ); @@ -408,37 +575,51 @@ After all the aspects have been bound, you need to call establishConnection() to // we're done! </pre> -<!--End Section h4--> -<!--End Section h3--> -<h3><a name="Editing Contexts">Editing Contexts</a></h3> -<p> -<a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOEditingContext.html">Editing contexts</a> allow multiple display groups to manipulate the same set of objects, such that objects edited in one display group are updated in the associations of all other display groups that contain that object. -</p> -<p> -Editing contexts monitor all inserts, edits, and deletes in the display groups that use them, allowing these sets of changes to be committed or rolled-back as a single transaction. -</p> -<p> -Furthermore, editing contexts can be nested, so that a new editing context will reflect the existing state of another editing context, but all changes made to the new context are not applied to the parent context until they have been committed in the child context. -</p> -<h4><a name="Object Stores">Object Stores</a></h4> -<p> -Two concepts are critical to an understanding of editing contexts: (1) An editing context must have an object store, and (2) an editing context is an object store. -</p> -<p> -Because you need an object store to instantiate an editing context, there must be some implementation of <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObjectStore.html">EOObjectStore</a> that is not an editing context. That object store will be responsible for directly reading and writing to the persistent storage. -</p> -<p> -Because editing contexts do implement object stores, you can then create other editing contexts that use the first editing context, which uses the first object store. This is what allows editing contexts to be nest. -</p> -<!--End Section h4--> -<h4><a name="Creating an Editing Context">Creating an Editing Context</a></h4> -<p> -To use an editing context in your application, you must create an object store. Your implementation of EOObjectStore will act as the glue between wotonomy and whatever persistent storage mechanism your application uses. -</p> -<p> -You will then create your primary editing context, specifying your object store as the parameter to the constructor. You will probably have only one object store per application, and one primary editing context that uses it. Any other editing contexts you create will use your primary context as their object store. -</p> -<pre> + <!--End Section h4--> + <!--End Section h3--> + <h3><a name="Editing Contexts">Editing Contexts</a></h3> + <p> + <a href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOEditingContext.html">Editing contexts</a> + allow multiple display groups to manipulate the same set of objects, such that objects edited in one display + group are updated in the associations of all other display groups that contain that object. + </p> + <p> + Editing contexts monitor all inserts, edits, and deletes in the display groups that use them, allowing these + sets of changes to be committed or rolled-back as a single transaction. + </p> + <p> + Furthermore, editing contexts can be nested, so that a new editing context will reflect the existing state of + another editing context, but all changes made to the new context are not applied to the parent context until + they have been committed in the child context. + </p> + <h4><a name="Object Stores">Object Stores</a></h4> + <p> + Two concepts are critical to an understanding of editing contexts: (1) An editing context must have an object + store, and (2) an editing context is an object store. + </p> + <p> + Because you need an object store to instantiate an editing context, there must be some implementation of <a + href="http://wotonomy.sourceforge.net/docs/net/wotonomy/control/EOObjectStore.html">EOObjectStore</a> that + is not an editing context. That object store will be responsible for directly reading and writing to the + persistent storage. + </p> + <p> + Because editing contexts do implement object stores, you can then create other editing contexts that use the + first editing context, which uses the first object store. This is what allows editing contexts to be nest. + </p> + <!--End Section h4--> + <h4><a name="Creating an Editing Context">Creating an Editing Context</a></h4> + <p> + To use an editing context in your application, you must create an object store. Your implementation of + EOObjectStore will act as the glue between wotonomy and whatever persistent storage mechanism your application + uses. + </p> + <p> + You will then create your primary editing context, specifying your object store as the parameter to the + constructor. You will probably have only one object store per application, and one primary editing context that + uses it. Any other editing contexts you create will use your primary context as their object store. + </p> + <pre> // initial application setup EOObjectStore objectStore = new MyObjectStore(); EOEditingContext mainContext = new EOEditingContext( objectStore ); @@ -450,20 +631,22 @@ You will then create your primary editing context, specifying your object store displayGroup.setDataSource( dataSource ); displayGroup.fetch(); </pre> -<!--End Section h4--> -<!--End Section h3--> -<!--End Section h2--> -<h2><a name="What's next?">What's next?</a></h2> -<p> -This document gives you a very basic overview and brief introduction to the major players in the wotonomy user interface framework. You'll probably want to check out the <a href="http://wotonomy.sourceforge.net/docs">API Reference</a> - next -</p> -<!--End Section h2--> -<br> -<hr> -<center><small><em> -This document was generated using <a href="http://www.maplefish.com/todd/aft.html">AFT v5.06</a> -</em></small></center> + <!--End Section h4--> + <!--End Section h3--> + <!--End Section h2--> + <h2><a name="What's next?">What's next?</a></h2> + <p> + This document gives you a very basic overview and brief introduction to the major players in the wotonomy user + interface framework. You'll probably want to check out the <a href="http://wotonomy.sourceforge.net/docs">API + Reference</a> + next + </p> + <!--End Section h2--> + <br> + <hr> + <center><small><em> + This document was generated using <a href="http://www.maplefish.com/todd/aft.html">AFT v5.06</a> + </em></small></center> </body> -</html> +</html>
\ No newline at end of file diff --git a/projects/net.wotonomy.all/src/site/resources/index-old.html b/projects/net.wotonomy.all/src/site/resources/index-old.html index d21e8c1..4ed4a5e 100644 --- a/projects/net.wotonomy.all/src/site/resources/index-old.html +++ b/projects/net.wotonomy.all/src/site/resources/index-old.html @@ -1,105 +1,140 @@ <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> + <head> -<title>wotonomy</title> + <title>wotonomy</title> <meta name="author" content=""> - <meta name="GENERATOR" content = "Almost Free Text v5.06; Copyright 1996-2000 Todd Coram. All rights reserved."> + <meta name="GENERATOR" content="Almost Free Text v5.06; Copyright 1996-2000 Todd Coram. All rights reserved."> </head> + <body> -<br><h1><a name="AFT-top"><center>wotonomy</center></a></h1> -<p> -Wotonomy is a pure java user interface framework for building both web and gui applications. It is heavily inspired by the NeXT and OpenStep APIs and it includes clean-room implementations of portions of the WebObjects and JavaClient frameworks. -</p> -<h2><a name="Useful links">Useful links</a></h2> -<ul> -<li> Developer Guide (for the user interface package)</li> -<ul> -<li> <a href="http://wotonomy.sourceforge.net/docs/ui-guide.html">http://wotonomy.sourceforge.net/docs/ui-guide.html</a></li> -</ul> -<li> API Reference (javadoc)</li> -<ul> -<li> <a href="http://wotonomy.sourceforge.net/docs">http://wotonomy.sourceforge.net/docs</a></li> -</ul> -<li> Sourceforge project page (includes downloads)</li> -<ul> -<li> <a href="http://sourceforge.net/projects/wotonomy">http://sourceforge.net/projects/wotonomy</a></li> -</ul> -<li> Browse the source repository</li> -<ul> -<li> <a href="http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/wotonomy">http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/wotonomy</a></li> -</ul> -<li> Download wotonomy library (includes demo, use java -jar to run)</li> -<ul> -<li> <a href="http://download.sourceforge.net/wotonomy/wotonomy.jar">http://download.sourceforge.net/wotonomy/wotonomy.jar</a></li> -</ul> -</ul> -<!-- AFT Table of Contents (auto generated) --> -<ul> -<li> <a href="#Frequently Asked Questions">Frequently Asked Questions</a></li> -<ul> -<li> <a href="#I'm a Java developer: what's in it for me?">I'm a Java developer: what's in it for me?</a></li> -<li> <a href="#I'm an OpenStep developer: what's in it for me?">I'm an OpenStep developer: what's in it for me?</a></li> -<li> <a href="#What's the current status?">What's the current status?</a></li> -<li> <a href="#Why not use GNUStep?">Why not use GNUStep?</a></li> -<li> <a href="#Why not use WebObjects?">Why not use WebObjects?</a></li> -<li> <a href="#Did you say MacOS9?">Did you say MacOS9?</a> + <br> + <h1><a name="AFT-top"> + <center>wotonomy</center> + </a></h1> + <p> + Wotonomy is a pure java user interface framework for building both web and gui applications. It is heavily + inspired by the NeXT and OpenStep APIs and it includes clean-room implementations of portions of the WebObjects + and JavaClient frameworks. + </p> + <h2><a name="Useful links">Useful links</a></h2> + <ul> + <li> Developer Guide (for the user interface package)</li> + <ul> + <li> <a + href="http://wotonomy.sourceforge.net/docs/ui-guide.html">http://wotonomy.sourceforge.net/docs/ui-guide.html</a> + </li> + </ul> + <li> API Reference (javadoc)</li> + <ul> + <li> <a href="http://wotonomy.sourceforge.net/docs">http://wotonomy.sourceforge.net/docs</a></li> + </ul> + <li> Sourceforge project page (includes downloads)</li> + <ul> + <li> <a href="http://sourceforge.net/projects/wotonomy">http://sourceforge.net/projects/wotonomy</a></li> + </ul> + <li> Browse the source repository</li> + <ul> + <li> <a + href="http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/wotonomy">http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/wotonomy</a> + </li> + </ul> + <li> Download wotonomy library (includes demo, use java -jar to run)</li> + <ul> + <li> <a + href="http://download.sourceforge.net/wotonomy/wotonomy.jar">http://download.sourceforge.net/wotonomy/wotonomy.jar</a> + </li> + </ul> + </ul> + <!-- AFT Table of Contents (auto generated) --> + <ul> + <li> <a href="#Frequently Asked Questions">Frequently Asked Questions</a></li> + <ul> + <li> <a href="#I'm a Java developer: what's in it for me?">I'm a Java developer: what's in it for me?</a> + </li> + <li> <a href="#I'm an OpenStep developer: what's in it for me?">I'm an OpenStep developer: what's in it for + me?</a></li> + <li> <a href="#What's the current status?">What's the current status?</a></li> + <li> <a href="#Why not use GNUStep?">Why not use GNUStep?</a></li> + <li> <a href="#Why not use WebObjects?">Why not use WebObjects?</a></li> + <li> <a href="#Did you say MacOS9?">Did you say MacOS9?</a> -</li> -</ul> -</ul> -<!--End Section h2--> -<h2><a name="Frequently Asked Questions">Frequently Asked Questions</a></h2> -<h3><a name="I'm a Java developer: what's in it for me?">I'm a Java developer: what's in it for me?</a></h3> -<p> -Java developers will find the design patterns in wotonomy useful for reducing the complexities of data-driven application development. Swing developers will additionally find a number of useful Swing components and utilities. -</p> -<!--End Section h3--> -<h3><a name="I'm an OpenStep developer: what's in it for me?">I'm an OpenStep developer: what's in it for me?</a></h3> -<p> -OpenStep developers will find that they can use familiar APIs while still writing pure java applications. Wotonomy provides clean-room and API-compatible implementations of the EOInterface/EOControl, WebObjects, and Foundation frameworks that interoperate with and extend the Java Swing, Servlet, and Collections packages respectively. Wotonomy tries to be as API-compatible as possible while still tightly integrating with Java. -</p> -<!--End Section h3--> -<h3><a name="What's the current status?">What's the current status?</a></h3> -<p> -The current status of the framework is alpha. The user interface package is suitable for simple to moderate application development and has working associations for all Swing components and a display group that supports data sources, sorting, and delegates. Editing contexts are in development. The web package is a proof-of-concept implementation that currently only supports WOString. The foundation package has pure java ports of all classes needed by the ui and web packages, including NSArray and NSDictionary classes that implement the List and Map interfaces respectively. -</p> -<!--End Section h3--> -<h3><a name="Why not use GNUStep?">Why not use GNUStep?</a></h3> -<p> -GNUStep is awesome, but it's an Objective-C framework. The new Java bridge is great, but even Apple is backpedaling on that approach with their pure-Java version of WebObjects, due to performance problems and conceptual difficulties in development. -</p> -<p> -Wotonomy has the same license (GNU Lesser Public License), and is written completely in Java. -</p> -<!--End Section h3--> -<h3><a name="Why not use WebObjects?">Why not use WebObjects?</a></h3> -<p> -Yes, you should if at all possible. Then you'll get tools like InterfaceBuilder and EOModeler and ProjectBuilder and you'll be even more productive. But some of us have to deploy applications on Windows or Linux or MacOS9. -</p> -<p> -It's not an issue of free beer: WebObjects is worth at least ten times the price (which is currently way cheap at ~$500). It's the restrictions on deployment that create the problem. -</p> -<p> -The other problem is political. Perhaps if enough people adopt wotonomy for their Java projects, they'll see the advantage of investing in Apple technology. Additionally, applications using wotonomy will be extremely portable to Apple platforms. -</p> -<!--End Section h3--> -<h3><a name="Did you say MacOS9?">Did you say MacOS9?</a></h3> -<p> -Yes, it should be possible to get wotonomy running on JDK1.1, although it doesn't work right now. The collections packages would have to be renamed and the weak references would have to be looked at, but it looks do-able. -</p> -<p> -If your application used only NSArrays and NSDictionaries and no java2 collections, you could just link your app against a version of the wotonomy library built for 1.1 and it will just work. -</p> -<hr> -<img src="http://sourceforge.net/sflogo.php?group_id=12936&type=1" alt="" align=bottom> -<!--End Section h3--> -<!--End Section h2--> -<br> -<hr> -<center><small><em> -This document was generated using <a href="http://www.maplefish.com/todd/aft.html">AFT v5.06</a> -</em></small></center> + </li> + </ul> + </ul> + <!--End Section h2--> + <h2><a name="Frequently Asked Questions">Frequently Asked Questions</a></h2> + <h3><a name="I'm a Java developer: what's in it for me?">I'm a Java developer: what's in it for me?</a></h3> + <p> + Java developers will find the design patterns in wotonomy useful for reducing the complexities of data-driven + application development. Swing developers will additionally find a number of useful Swing components and + utilities. + </p> + <!--End Section h3--> + <h3><a name="I'm an OpenStep developer: what's in it for me?">I'm an OpenStep developer: what's in it for me?</a> + </h3> + <p> + OpenStep developers will find that they can use familiar APIs while still writing pure java applications. + Wotonomy provides clean-room and API-compatible implementations of the EOInterface/EOControl, WebObjects, and + Foundation frameworks that interoperate with and extend the Java Swing, Servlet, and Collections packages + respectively. Wotonomy tries to be as API-compatible as possible while still tightly integrating with Java. + </p> + <!--End Section h3--> + <h3><a name="What's the current status?">What's the current status?</a></h3> + <p> + The current status of the framework is alpha. The user interface package is suitable for simple to moderate + application development and has working associations for all Swing components and a display group that supports + data sources, sorting, and delegates. Editing contexts are in development. The web package is a proof-of-concept + implementation that currently only supports WOString. The foundation package has pure java ports of all classes + needed by the ui and web packages, including NSArray and NSDictionary classes that implement the List and Map + interfaces respectively. + </p> + <!--End Section h3--> + <h3><a name="Why not use GNUStep?">Why not use GNUStep?</a></h3> + <p> + GNUStep is awesome, but it's an Objective-C framework. The new Java bridge is great, but even Apple is + backpedaling on that approach with their pure-Java version of WebObjects, due to performance problems and + conceptual difficulties in development. + </p> + <p> + Wotonomy has the same license (GNU Lesser Public License), and is written completely in Java. + </p> + <!--End Section h3--> + <h3><a name="Why not use WebObjects?">Why not use WebObjects?</a></h3> + <p> + Yes, you should if at all possible. Then you'll get tools like InterfaceBuilder and EOModeler and ProjectBuilder + and you'll be even more productive. But some of us have to deploy applications on Windows or Linux or MacOS9. + </p> + <p> + It's not an issue of free beer: WebObjects is worth at least ten times the price (which is currently way cheap + at ~$500). It's the restrictions on deployment that create the problem. + </p> + <p> + The other problem is political. Perhaps if enough people adopt wotonomy for their Java projects, they'll see the + advantage of investing in Apple technology. Additionally, applications using wotonomy will be extremely portable + to Apple platforms. + </p> + <!--End Section h3--> + <h3><a name="Did you say MacOS9?">Did you say MacOS9?</a></h3> + <p> + Yes, it should be possible to get wotonomy running on JDK1.1, although it doesn't work right now. The + collections packages would have to be renamed and the weak references would have to be looked at, but it looks + do-able. + </p> + <p> + If your application used only NSArrays and NSDictionaries and no java2 collections, you could just link your app + against a version of the wotonomy library built for 1.1 and it will just work. + </p> + <hr> + <img src="http://sourceforge.net/sflogo.php?group_id=12936&type=1" alt="" align=bottom> + <!--End Section h3--> + <!--End Section h2--> + <br> + <hr> + <center><small><em> + This document was generated using <a href="http://www.maplefish.com/todd/aft.html">AFT v5.06</a> + </em></small></center> </body> -</html> +</html>
\ No newline at end of file diff --git a/projects/net.wotonomy.all/src/site/site.xml b/projects/net.wotonomy.all/src/site/site.xml index 65ae393..4b96c6b 100644 --- a/projects/net.wotonomy.all/src/site/site.xml +++ b/projects/net.wotonomy.all/src/site/site.xml @@ -1,37 +1,41 @@ <?xml version="1.0" encoding="UTF-8"?> <project name="${project.name}"> - <bannerLeft> - <name>${project.name}</name> - </bannerLeft> - <bannerRight> - <src>http://sourceforge.net/sflogo.php?group_id=12936&type=1</src> - </bannerRight> - <body> - - <menu ref="parent" inherit="top" /> - <menu name="Wotonomy Documentation"> - <item name="FAQ" href="faq.html" /> - <item name="UI Developer's Guide" href="doc/ui-guide.html" /> - <item name="Persistence Control Guide" href="doc/control-guide.txt" /> - </menu> - <menu ref="modules" /> - <menu ref="reports" /> - + <bannerLeft> + <name>${project.name}</name> + </bannerLeft> + <bannerRight> + <src>http://sourceforge.net/sflogo.php?group_id=12936&type=1</src> + </bannerRight> + <body> + + <menu ref="parent" inherit="top" /> + <menu name="Wotonomy Documentation"> + <item name="FAQ" href="faq.html" /> + <item name="UI Developer's Guide" href="doc/ui-guide.html" /> + <item name="Persistence Control Guide" href="doc/control-guide.txt" /> + </menu> + <menu ref="modules" /> + <menu ref="reports" /> + <menu name="Developer Instructions"> - <item name="Project Folder Layout" href="layout.html" /> - <item name="Source Control Help" href="scm.html" /> - <item name="Build Help" href="build.html" /> - <item name="Eclipse Help" href="eclipse.html" /> + <item name="Project Folder Layout" href="layout.html" /> + <item name="Source Control Help" href="scm.html" /> + <item name="Build Help" href="build.html" /> + <item name="Eclipse Help" href="eclipse.html" /> </menu> - <menu name="Downloads" inherit="bottom" > - <item name="wotonomy packages" href="http://sourceforge.net/project/showfiles.php?group_id=12936"/> + <menu name="Downloads" inherit="bottom"> + <item name="wotonomy packages" + href="http://sourceforge.net/project/showfiles.php?group_id=12936" /> </menu> - <menu name="Links" inherit="bottom" > - <item name="Sourceforge Project" href="http://www.sourceforge.net/projects/wotonomy/" /> - <item name="Israfil Maven Repository" href="http://www.israfil.net/maven2/" /> - <item name="Browse Sourceforge Repository" href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wotonomy/wotonomy/" /> + <menu name="Links" inherit="bottom"> + <item name="Sourceforge Project" + href="http://www.sourceforge.net/projects/wotonomy/" /> + <item name="Israfil Maven Repository" + href="http://www.israfil.net/maven2/" /> + <item name="Browse Sourceforge Repository" + href="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wotonomy/wotonomy/" /> </menu> - - </body> + + </body> </project> diff --git a/projects/net.wotonomy.datastore/src/main/java/net/wotonomy/datastore/package.html b/projects/net.wotonomy.datastore/src/main/java/net/wotonomy/datastore/package.html index 7ca944c..3c6076c 100644 --- a/projects/net.wotonomy.datastore/src/main/java/net/wotonomy/datastore/package.html +++ b/projects/net.wotonomy.datastore/src/main/java/net/wotonomy/datastore/package.html @@ -1,19 +1,19 @@ <body> -<p> -A "low technology" object database, suitable -for simple application persistence. The design -goal is to simply store, retrieve, and query -arbitrary java objects that need no knowledge of -how they are to be persisted. -</p> -<p> -DataSoup is the primary interface, with -SerializedFileSoup and XMLFileSoup being the -primary implementations. Both implementations -persist arbitrary java objects to the file system, -with some limitations. -</p> -<p> -This package has dependencies on the util package. -</p> -</body> + <p> + A "low technology" object database, suitable + for simple application persistence. The design + goal is to simply store, retrieve, and query + arbitrary java objects that need no knowledge of + how they are to be persisted. + </p> + <p> + DataSoup is the primary interface, with + SerializedFileSoup and XMLFileSoup being the + primary implementations. Both implementations + persist arbitrary java objects to the file system, + with some limitations. + </p> + <p> + This package has dependencies on the util package. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.foundation/src/main/java/net/wotonomy/foundation/package.html b/projects/net.wotonomy.foundation/src/main/java/net/wotonomy/foundation/package.html index c52ca95..93e7b48 100644 --- a/projects/net.wotonomy.foundation/src/main/java/net/wotonomy/foundation/package.html +++ b/projects/net.wotonomy.foundation/src/main/java/net/wotonomy/foundation/package.html @@ -1,18 +1,18 @@ <body> -<p> -A set of collections classes that are needed -by the ui and web packages. These correspond -to the foundation classes in the OpenStep -specification. -</p> -<p> -These classes for the most part extend their -java counterparts, adding methods to be API -compatible with the OpenStep specification. -In this way, they retain compatibility with -the Java Collections APIs. -</p> -<p> -This package has no external dependencies. -</p> -</body> + <p> + A set of collections classes that are needed + by the ui and web packages. These correspond + to the foundation classes in the OpenStep + specification. + </p> + <p> + These classes for the most part extend their + java counterparts, adding methods to be API + compatible with the OpenStep specification. + In this way, they retain compatibility with + the Java Collections APIs. + </p> + <p> + This package has no external dependencies. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.persistence/src/main/java/net/wotonomy/control/package.html b/projects/net.wotonomy.persistence/src/main/java/net/wotonomy/control/package.html index c32d3c7..ecba32b 100644 --- a/projects/net.wotonomy.persistence/src/main/java/net/wotonomy/control/package.html +++ b/projects/net.wotonomy.persistence/src/main/java/net/wotonomy/control/package.html @@ -1,6 +1,6 @@ <body> -<p> -Support classes needed by the ui and web packages. -This package roughly corresponds to the eocontrol package. -</p> -</body> + <p> + Support classes needed by the ui and web packages. + This package roughly corresponds to the eocontrol package. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/components/package.html b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/components/package.html index 618651b..026ecfc 100644 --- a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/components/package.html +++ b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/components/package.html @@ -1,26 +1,26 @@ <body> -<p> -Contains various and useful Swing components. -These can be used in conjunction with -the ui framework, however, there are no -dependencies and all of these components can be used -independently of the rest of the framework. -</p> -<p> -Of note are the ButtonPanel classes, which -automate the placement and layout of buttons -in a manner consistent with the Java Look and Feel -guidelines. This uses the BetterFlowLayout which -is another useful class. -</p> -<p> -Also of note is the InfoPanel, which automates -the placement and layout of labeled fields on -a panel. -</p> -<p> -And the -various cell renderer and editor components can -be useful as well. -</p> -</body> + <p> + Contains various and useful Swing components. + These can be used in conjunction with + the ui framework, however, there are no + dependencies and all of these components can be used + independently of the rest of the framework. + </p> + <p> + Of note are the ButtonPanel classes, which + automate the placement and layout of buttons + in a manner consistent with the Java Look and Feel + guidelines. This uses the BetterFlowLayout which + is another useful class. + </p> + <p> + Also of note is the InfoPanel, which automates + the placement and layout of labeled fields on + a panel. + </p> + <p> + And the + various cell renderer and editor components can + be useful as well. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/package.html b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/package.html index 574cc7b..894a3d7 100644 --- a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/package.html +++ b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/package.html @@ -1,21 +1,21 @@ <body> -<p> -Contains associations designed for use -with the Swing framework. -</p> -<p> -In general, most text components can use the -TextAssociation, and most buttons, including -checkboxes and radio buttons, can use the -ButtonAssociation. -</p> -<p> -Tables are handled with the TableColumnAssociation -by dealing with TableColumns that are later added -to a table. -</p> -<p> -The TreeAssociation will handle any component that -uses a TreeModel and a TreeSelectionModel. -</p> -</body> + <p> + Contains associations designed for use + with the Swing framework. + </p> + <p> + In general, most text components can use the + TextAssociation, and most buttons, including + checkboxes and radio buttons, can use the + ButtonAssociation. + </p> + <p> + Tables are handled with the TableColumnAssociation + by dealing with TableColumns that are later added + to a table. + </p> + <p> + The TreeAssociation will handle any component that + uses a TreeModel and a TreeSelectionModel. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/util/package.html b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/util/package.html index 97f1598..24aeea0 100644 --- a/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/util/package.html +++ b/projects/net.wotonomy.ui.swing/src/main/java/net/wotonomy/ui/swing/util/package.html @@ -1,6 +1,6 @@ <body> -<p> -Contains utilities that ease Swing development -but don't quite qualify as components. -</p> -</body> + <p> + Contains utilities that ease Swing development + but don't quite qualify as components. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.ui/src/main/java/net/wotonomy/ui/package.html b/projects/net.wotonomy.ui/src/main/java/net/wotonomy/ui/package.html index 710c57b..5eb816f 100644 --- a/projects/net.wotonomy.ui/src/main/java/net/wotonomy/ui/package.html +++ b/projects/net.wotonomy.ui/src/main/java/net/wotonomy/ui/package.html @@ -1,14 +1,14 @@ <body> -<p> -An implementation of the JavaClient -framework. It tries to be API-compatible at the -EODisplayGroup and EOAssociation layer. The -associations themselves are inspired by their EO -counterparts, but are extended so as to be -more useful for java application development. -</p> -<p> -This package has dependencies on the control, -foundation, and util packages. -</p> -</body> + <p> + An implementation of the JavaClient + framework. It tries to be API-compatible at the + EODisplayGroup and EOAssociation layer. The + associations themselves are inspired by their EO + counterparts, but are extended so as to be + more useful for java application development. + </p> + <p> + This package has dependencies on the control, + foundation, and util packages. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/package.html b/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/package.html index 10bef50..ea7f50b 100644 --- a/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/package.html +++ b/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/package.html @@ -1,11 +1,11 @@ <body> -<p> -An implementation of the WebObjects -framework. It tries to be API-compatible to the -maximum extent possible. -</p> -<p> -This package has dependencies on the foundation -and util packages. -</p> -</body> + <p> + An implementation of the WebObjects + framework. It tries to be API-compatible to the + maximum extent possible. + </p> + <p> + This package has dependencies on the foundation + and util packages. + </p> +</body>
\ No newline at end of file diff --git a/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/xml/package.html b/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/xml/package.html index 4303e07..73ac898 100644 --- a/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/xml/package.html +++ b/projects/net.wotonomy.web/src/main/java/net/wotonomy/web/xml/package.html @@ -1,30 +1,30 @@ <body> -<p> -The XML object serialization framework, including -an XML-RPC serializer implementation and an easy-to-use -XML-RPC servlet and client. -</p> -<p> -The primary serialization interfaces are XMLEncoder and XMLDecoder. -</p> -<p> -The implementation of those interfaces is in XMLRPCEncoder and XMLRPCDecoder. -In addition to serializing java objects to an XML-RPC struct format, these -classes also define methods for generating and parsing XML-RPC requests, -responses, and faults. Other implementations (like SOAP) may follow. -</p> -<p> -The XMLRPCServlet utilizes the framework to allow you to turn any -java object into an XML-RPC server with one line of code. -</p> -<p> -XMLRPCSelector turns NSSelector into a XML-RPC client. If you -pass in a URL as the target object, the selector will invoke its -method on the specified XML-RPC server and return the result as -a java object. The selector otherwise works normally. -</p> -<p> -This package has dependencies on the foundation and util packages. -The servlet has a dependency on javax.servlet.HttpServlet. -</p> -</body> + <p> + The XML object serialization framework, including + an XML-RPC serializer implementation and an easy-to-use + XML-RPC servlet and client. + </p> + <p> + The primary serialization interfaces are XMLEncoder and XMLDecoder. + </p> + <p> + The implementation of those interfaces is in XMLRPCEncoder and XMLRPCDecoder. + In addition to serializing java objects to an XML-RPC struct format, these + classes also define methods for generating and parsing XML-RPC requests, + responses, and faults. Other implementations (like SOAP) may follow. + </p> + <p> + The XMLRPCServlet utilizes the framework to allow you to turn any + java object into an XML-RPC server with one line of code. + </p> + <p> + XMLRPCSelector turns NSSelector into a XML-RPC client. If you + pass in a URL as the target object, the selector will invoke its + method on the specified XML-RPC server and return the result as + a java object. The selector otherwise works normally. + </p> + <p> + This package has dependencies on the foundation and util packages. + The servlet has a dependency on javax.servlet.HttpServlet. + </p> +</body>
\ No newline at end of file diff --git a/projects/pom.xml b/projects/pom.xml index 8068def..7c46448 100644 --- a/projects/pom.xml +++ b/projects/pom.xml @@ -12,29 +12,34 @@ </modules> <ciManagement> <system>continuum</system> - </ciManagement> + </ciManagement> <distributionManagement> <!-- use the following if you're not using a snapshot version. --> <repository> <id>israfil</id> <name>Israfil Deploy</name> - <url>scp://mikail.israfil.net/var/www/vhosts/www.israfil.net/htdocs/maven2</url> + <url> + scp://mikail.israfil.net/var/www/vhosts/www.israfil.net/htdocs/maven2</url> <!--<url>file:///E:/tmp/i-deploy</url>--> </repository> <!-- use the following if you ARE using a snapshot version. --> <snapshotRepository> <id>israfil</id> <name>Israfil Snapshot</name> - <url>scp://mikail.israfil.net/var/www/vhosts/www.israfil.net/htdocs/maven2</url> + <url> + scp://mikail.israfil.net/var/www/vhosts/www.israfil.net/htdocs/maven2</url> <!--<url>file:///E:/tmp/i-deploy</url>--> </snapshotRepository> <site> <id>website</id> - <url>scp://cgruber@shell.sourceforge.net/home/groups/w/wo/wotonomy/htdocs</url> + <url> + scp://cgruber@shell.sourceforge.net/home/groups/w/wo/wotonomy/htdocs</url> </site> </distributionManagement> <scm> - <connection>scm:svn:https://svn.sourceforge.net/svnroot/wotonomy/trunk/projects</connection> - <developerConnection>scm:svn:https://svn.sourceforge.net/svnroot/wotonomy/trunk/projects</developerConnection> + <connection> + scm:svn:https://svn.sourceforge.net/svnroot/wotonomy/trunk/projects</connection> + <developerConnection> + scm:svn:https://svn.sourceforge.net/svnroot/wotonomy/trunk/projects</developerConnection> </scm> </project> |