Editing JTree Properties (AKA no instanceof)

[Jason Cavett]

I am developing an application that displays a JTree and shows
different options based on what the user clicks within the JTree. I
have already populated this JTree. What I'd like to be able to do now
is to display a properties window when I double click on an item in the
JTree.

The objects that I'm placing in the tree are data-type objects (model
objects, I guess). Additionally, there are different views that will
be shown depending on what I have selected in the tree. Unfortunately,
the only way I can figure out how to display the correct view is to do
an "instanceof" to determine what object is selected so I can open the
correct view. This definitely doesn't seem like a good approach.

So, I've tried a few things, but I am kind of stuck on where I should
go. The only other thing I could come up with is to use the
"View"-type objects to populate the tree, then, when the object is
selected, I just do a viewObject.show() so it appears and, of course,
the view object knows about its underlying model.

Whew..I hope that made sense. Can anybody give me any suggestions or
comment on my potential solution?


Thanks

 

[Wesley Hall]

I am developing an application that displays a JTree and shows
different options based on what the user clicks within the JTree. I
have already populated this JTree. What I'd like to be able to do now
is to display a properties window when I double click on an item in the
JTree.

The objects that I'm placing in the tree are data-type objects (model
objects, I guess). Additionally, there are different views that will
be shown depending on what I have selected in the tree. Unfortunately,
the only way I can figure out how to display the correct view is to do
an "instanceof" to determine what object is selected so I can open the
correct view. This definitely doesn't seem like a good approach.

So, I've tried a few things, but I am kind of stuck on where I should
go. The only other thing I could come up with is to use the
"View"-type objects to populate the tree, then, when the object is
selected, I just do a viewObject.show() so it appears and, of course,
the view object knows about its underlying model.

Whew..I hope that made sense. Can anybody give me any suggestions or
comment on my potential solution?


Thanks

This is the job of your controller.

When the user selects a tree node, your controller should receive the
event and know, via it's configuration, which view to associate with the
resulting model object.

The configuration could be as simple as a properties file that looks
something like this...

com.myproject.model.ModelType1=com.myproject.view.ViewType1
com.myproject.model.ModelType2=com.myproject.view.ViewType2

At start up, this is parsed into a map that looks something like this..

Map<Class<? extends Model>, Class<? extends View>> viewMap;

When a node is selected you use a viewMap.get to pull the appropriate
view class out of the map and instansiate it reflectively.

The controller then passes the model to the view and displays it.

Beyond this you can get more sophisticated, with interfaces like
ViewFactory etc, but it is this basic mechanism that you should aim
towards. Let your controller integrate your models and views.

 

[Jason Cavett]

When the user selects a tree node, your controller should receive the
event and know, via it's configuration, which view to associate with the
resulting model object.

The configuration could be as simple as a properties file that looks
something like this...

com.myproject.model.ModelType1=com.myproject.view.ViewType1
com.myproject.model.ModelType2=com.myproject.view.ViewType2

At start up, this is parsed into a map that looks something like this..

Map<Class<? extends Model>, Class<? extends View>> viewMap;

When a node is selected you use a viewMap.get to pull the appropriate
view class out of the map and instansiate it reflectively.

The controller then passes the model to the view and displays it.

Beyond this you can get more sophisticated, with interfaces like
ViewFactory etc, but it is this basic mechanism that you should aim
towards. Let your controller integrate your models and views.- Hide quoted text -- Show quoted text -

Okay, I didn't think of having a config file and using reflection.

Since you mentioned a factory, would it also be feasible (from a poor
design vs. good design standpoint) to use an overloaded factory class?
It's kind of the same idea, but instead of having a properties file, I
have the class enforce everything.

 

[wesley.hall]

Since you mentioned a factory, would it also be feasible (from a poor
design vs. good design standpoint) to use an overloaded factory class?
It's kind of the same idea, but instead of having a properties file, I
have the class enforce everything.

I am not exactly sure what you mean here, but it doesn't matter. As
long as it is your controller that is linking your model and views and
displaying the views based on user action, then how you inform your
controller of which views go with which models is entirely your choice.


The solution that I mentioned was not my idea of a perfect solution,
there are short comings in this approach too, but it is "on the right
track" in terms of MVC. I did not want to dilute that message with lots
of stylistic stuff and I certainly wouldn't want to deprive you of the
enjoyment (and wonderful learning experience) of designing your own
software. Good luck!