views:

118

answers:

3

The overall structure of a given software system is model view controller. The view (graphical interface) is a representation of the model (domain object models).

However, within the view (graphical interface) there are components (such as JTextComponent). These components too are arranged in Model View Controller. JTextComponent uses Document as its model.

The JTextComponent is meant to represent a specific part of a domain object model. But its model is actually the Document object.

This one piece of information, portrayed by the JTextComponent, is stored both in the JTextComponent Document and in the domain object model. This organisation results in this information of the model being duplicated. And thus the two models need to be kept synchronised. Violation of DRY.

Are there any elegant solutions for binding a JTextComponent (or any graphical Component) to a part of the domain object model, so there truly is one place for the data?

+2  A: 

Make a Document object of your own, in your object model.

Then use the setDocument(d) method.

Yuval A
Or a constructor that takes a Document.
Tom Hawtin - tackline
+1  A: 

If I understand right you are facing parallel containment hierarchy.

enter code here
                   view  -----------------------> Model
                     |
                     v
                 TextArea------------------------>Document

And your concern is that the data in Model needs to be present in Document too. The most elegant way to address this is to drive the Document off the Model itself, i.e. make Document a window on the overall Model.

I think Yuval is suggesting the same thing.

Hemal Pandya
+1  A: 

There are a couple of things going on here.

The Java framework is offering you a nice way updated your UI but constrains you to using a specific structure, Document.

On the other hand you have a adequate model that represents your data. By using Document directly in your model you also take the risks of tying your model to a specific framework. Which isn't a good idea.

The Java Document framework offers the ability to listen to changes you can leverage this into creating an Adapter class between your model and Document. Basically when you setup the form you will make an instance of the adapter class. You will initialize with your model. The adapter will have a property returning a document. IN addition the Adapter will register itself as the listener for that document model. The adapter will be smart enough to know how to translate the chances to the document model to your model.

Goes something like this

  1. UI is Created along with the JTextDocument.
  2. In the creation process it requests your model from the View.
  3. It create an instance of the Adapter initializing it with your model.
  4. The adapter also sets itself up as the listener of the Document.
  5. Assign the document to the JTextDocument object.
  6. Any interaction with the Document is reported back to Adapter
  7. The Adapter notifies the View passing the translated data back.
  8. The View changes the Model.
  9. The View nofitifies the Adapter that the model has change.
  10. The Adapter translates the changes into changes to the document.

Because the adapter is tied to the Java Framework is should be pushed as close to the UI as it can get. Likely the Adapter will implement a interface exposed by the View so that the View doesn't have to reference anything specific to the framework you are using. When you change framework all you have to do is make a new object that implements that interface and the View is none the wiser.

RS Conley