OO GUI programming is essentially specifying a large, complex data structure, and then mapping parts of that structure to some underlying objects. It is of more than academic interest how this mapping should occur, and what the best way to achieve this mapping is.

Ignoring fields for the moment, every Java object is a collection of methods. A basic Java program allows the user to set parameters and execute methods with those parameters in succession. The user is presented with the state of this object (output) and specifies parameters (input) and executes these methods.

All widgets either help the user visualize object state and/or help the user specify parameters. Every method can be thought of as a collection of widgets. Every object is a collection of methods, hence is also a collection of widgets. I propose that each method has a domain of valid inputs, and that the widget should reflect this as proactively as possible, and that the widget should receive this domain information directly from its underlying method.

Using high-level Swing components, the type of data that a user can specify is limited to picking items out of a list (a number plus context), and strings.

What does one do with the return value from a method, if any? The default behavior would be to present the user with another Jframe that displays the results. How does a user specify complex parameters to methods? These can only be set under two circumstances: an object already exists, and the user visually places it in the parameter, or the user creates a new object of that type. Note that this constructor might need an intermediate object constructed, which could get ugly.

Obviously such a raw presentation would be unwieldy and not very user friendly. In particular, there is no visual representation of the relationship between objects. This is OK when we are dealing with semi-autonomous objects - that is, objects whose methods only self-mutate. The bottom line is the context in which these objects are living is potentially very large, and the relationships are not always clear.

Lets focus on two types of domains: strings and lists. String domains are pretty simple. What about lists? The key here is to use a list type widget (Jcombobox, Jlist). Again, the key for a UIFactory is the Domain describing the particular method.

Its hard to maintain consistency between real objects and their internal representations. Therefore, the amount of state in an object should be kept to a minimum.

Real life objects have many relationships to each other, which are hinted at by OO. In terms of physics though, one can look at reality as a containment hierarchy, and partition state into space and time.

Let me also say that I hate computer graphics, Java, HTML, XML, TCP/IP, Sockets, Windows, and Office. Its all bullshit. There was a time when database records were fundamental: now everything has to be a fucking Java object representing an XML file loaded over the Internet. I fucking hate it all, this goddamn technology. I wish it all just died. Then we could go back to the basics: fucking our women, hunting with our dogs, and eating our steaks. Yeah.

But information is power, and computers are information. Programming is the key to this power. Power is the key to women, dogs, and steaks. To be useful data must be accessible. To be accessible is to be vulnerable. Who are we, really? The knowledge in our heads. Even that information is power: our own fucking knowledge.

The most fundamental relationship is containment. All data can be modeled like this. Therefore, in this framework, special care needs to be taken with this relatioship. That is why my VisualCollection framework is so important. But this VisualCollection is just a special case of my VisualObject framework, which is built up from VisualMethods.

The simplest case is a single VisualObject (VO) with methods that take only literals, return only Strings, primitives, or null, and have no extra-object side effects. Here we need to deal with converting Strings to arbitrary primitive data types, and converting other widget states to parameters, and parameters to widget states. Already we see that some user input can be invalid, even if domains are not coupled (for example, a user might enter text where a number is needed). The domain itself must now express itself in the VO using widgets - for example beeping and preventing further input in a text field, or disabling a method invocation button. Next we allow Domains to be coupled - this cooresponds to 'record level' validation in DB terminology. This is not so much a VO issue as a Domain issue, though. Next, we add the ability of a VisualMethod to return a VisualObject that is itself contained within the main VisualObject.