• Post Reply Bookmark Topic Watch Topic
  • New Topic

Document, Element and View Derivations

 
Chris Beckey
Ranch Hand
Posts: 116
Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Background: Experienced Java/J2EE and Beginner/Intermediate Swing Developer. I've written a few AWT/Swing applications in the past and usually end up implementing some kind of MVC framework. Currently I'm writing a rather simple application (just a test driver) so I was hoping to avoid the complexity of writing my own MVC or of using an existing framework.
Problem example: Implement a Swing Panel editing a value object representing URL components (for example; protocol, port, host, etc.). There is a one-to-one correspondence between the value object fields and the UI components, i.e. a drop-down list for the protocol and text boxes for each of host, port, etc ... The value object may be updated from either the panel or from other code. Updates to the value object must also be reflected in a label (a title bar showing the URL). For those reasons, some kind of MVC seems warranted.
My first thought was to implement a javax.swing.text.Document that would act as a decorator over the value object and essentially map changes to the fields in the value object.
After a bit more investigation I implemented a factory creating Document and javax.swing.text.Element implementations for each field and component. The factory itself maps to a single instance of the value object (in that respect its not named well). This approach shows signs of working but to say it is cumbersome would be an understatement. In particular it is starting to look like I'll need to implement View derivations.
My questions (for some experienced Swing person) are:
Am I just going down the wrong path?
Is there an example using Document and Element implementations specific to an application?
Do you know of a simple MVC type framework that provides something like component to field binding?
Can you recommend good Swing books that address this kind of application?

Thanks
 
Brian Cole
Author
Ranch Hand
Posts: 920
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you are going down the wrong path.

Element/View stuff is pretty advanced and the problem statement sounds pretty simple.

one-to-one correspondence between the value object fields and the UI components, i.e. a drop-down list for the protocol and text boxes for each of host, port, etc


From your description I'm not sure exactly how you were attempting to do this, but it sounds like you were trying to do it with just one UI component, not with one for each field.

I would think you would want a JComboBox for the protocol and JTextFields (or perhaps JFormattedTextFields) for the host and port. Each JTextField will have its own Document, but I don't see why you would need to manipulate Documents directly.
 
Chris Beckey
Ranch Hand
Posts: 116
Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think I explained myself well enough in the first post ... though I still may be going down the wrong path.

If I could do what I wanted to do:
I would have one Document that was the value object (the model). Then I'd have Element instances representing each field in the value object (protocol, host, port, etc ...). The UI Component instances (protocol JComboBox, host JTextField, etc...) would each view an Element instance. I'd also be able to have additional Component instances (title) that was a View over the same value object.
All the event handling (changes in Component to Element and then back up to the Component instances) would then happen automagically.
That's what I would like to have but I get the feeling I'm kinda out to luch on this.
 
Brian Cole
Author
Ranch Hand
Posts: 920
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess one thing you need to ask yourself is, do you want to implement this in a bizarre way, or in a way typical of how most Swing programmers would implement it.

If the former, then perhaps your desired approach could be maintained, but it would take a lot of effort. I wouldn't recommend it for a "Beginner/Intermediate Swing Developer," and probably not for anyone else either.

Keep in mind that each JComponent is pretty much hard-wired to use a particular kind of model. JCombobox probably uses DefaultComboBoxModel (ComboBoxModel interface). JTextField probably uses PlainDocument (Document interface). They just aren't made to use a javax.swing.text.Element as a model.

One option is to more or less rewrite JComboBox and JTextField so that they can accept an Element as a model. Do this only if you like a good challenge.

Another option is to create implementations of ComboBoxModel and Document that wrap an Element. I guess this wouldn't be too hard, but it seems kind of pointless.


Better, I think, is to just use a DefaultComboBoxModel for the url protocol, and PlainDocuments for the host and port. Probably easiest is to not even mess with the models explicity. Just use the JComboBox and JTextField constructors and methods [such as JComboBox.addItem() and JTextField.setText()] and they will manipulate the models for you behind the scenes.
 
Chris Beckey
Ranch Hand
Posts: 116
Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Brian, thanks for the help. You've convinced me.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!