Advice on MVC issue
Hi,
I'm currently designing a fairly standard document editing application. I have a number of seperate sets of classes representing different types of documents. Many of these different documents can be viewed in the same way - eg as a tree, and many can be viewed in more than one way - eg as a tree and as a grid. Currently my strategy is to have make my document classes implement generic tree/grid interfaces. I have also created generic TreeView and GridView components, which are able to "view" any object which implements the appropriate interfaces.
So far this has worked well, but subtly, I need the viewing components to work different for each different type of document - eg I want to view Surveys and Organizations slightly differently (both implment ITreeModel). I really want to implement SurveyView and OrganizationView components seperately, but I can't find a way to do this without losing lots of code re-use, because as soon as I start dealing with Surveys and Organizations specifically, I loose the flexibility of just dealing with the ITreeModel interface.
Any suggestions?
[1126 byte] By [
alexflinta] at [2007-10-2 2:03:32]
> I need the viewing components to work different for each different type of document
What do you want to do differently?
Do you mean that in both cases you have a tree or a grid but you want to display the "content" of the two types differently?
If so, have a look at how standard swing components cater for this sort of thing.
For example, JTree lets you set custom TreeCellRenderers.
Maybe you want something similar, where you can plug in the rendering for a viewed component based on its type or what-ever.
So far this has worked well, but subtly, I need the viewing components to work different for each different type of document - eg I want to view Surveys and Organizations slightly differently (both implment ITreeModel). I really want to implement SurveyView and OrganizationView components seperately, but I can't find a way to do this without losing lots of code re-use, because as soon as I start dealing with Surveys and Organizations specifically, I loose the flexibility of just dealing with the ITreeModel interface.
You can still have the interface. Refactor the common code into an abstract class that is ancestor to Survey and Organization. Or, create a helper class and have Survey and Organization delegate their calls to that common object.
- Saish
Saisha at 2007-7-15 19:44:58 >
> Currently my strategy is to have make my document> classes implement generic tree/grid interfaces.This sounds to me like you are making model types implement view interfaces. If that's the case, you may be missing the point of MVC.
What do you want to do differently?
Do you mean that in both cases you have a tree or a grid but you want to display the "content" of the two types differently?What do you want to do differently?
Do you mean that in both cases you have a tree or a grid but you want to display the "content" of the two types differently?
If so, have a look at how standard swing components cater for this sort of thing.
For example, JTree lets you set custom TreeCellRenderers.
Maybe you want something similar, where you can plug in the rendering for a viewed component based on its type or what-ever.
Basically my document types all implement ITreeModel so all of them get displayed as a basic "tree". However, in some cases I want to change things such as context menus, some small behavioural aspects etc. I'll have a look at JTree - thanks (I'm actually not using java but it looks like I should check out the swing design patterns).
You can still have the interface. Refactor the common code into an abstract class that is ancestor to Survey and Organization. Or, create a helper class and have Survey and Organization delegate their calls to that common object.
I think I will try this. I haven't been able to come up with a clean way of sharing common functionality through inheritance yet but I'll keep trying...
This sounds to me like you are making model types implement view interfaces. If that's the case, you may be missing the point of MVC.
Hmmm... maybe. The various data models in my application implement what I think of as standard data interfaces (ie TreeModel, GridModel etc). These interfaces are meant to represent tree/grid data structures, rather than representing any aspect of the view. My XxxView components (TreeView, GridView etc) are seperate from these interfaces.
> This sounds to me like you are making model types
> implement view interfaces. If that's the case, you
> may be missing the point of MVC.
>
> Hmmm... maybe. The various data models in my
> application implement what I think of as standard
> data interfaces (ie TreeModel, GridModel etc). These
> interfaces are meant to represent tree/grid data
> structures, rather than representing any aspect
> of the view. My XxxView components (TreeView,
> GridView etc) are seperate from these interfaces.
This is a common confusion, I find. Swing has a MVC architecture, however, this is not the kind of MVC you need. Swings is generic and geared towards display.
In terms of your MVC architecture, you should consider TreeModels and ModelsViews to be parts of the View layer, not the model layer. Your model layer should have no references to any sort of displaying of data.
You will probably want to create TreeModel and GridModel classes, however, these will wrap your Model classes. You should have only one Data Model API for each data type in your system. Otherwise you will end up with a maintenance nightmare.
> > This sounds to me like you are making model types
> > implement view interfaces. If that's the case, you
> > may be missing the point of MVC.
> >
> > Hmmm... maybe. The various data models in my
> > application implement what I think of as standard
> > data interfaces (ie TreeModel, GridModel etc).
> These
> > interfaces are meant to represent datastructures,
> > rather than representing any aspect of the view.
>
> This is a common confusion, I find. Swing has a MVC
> architecture, however, this is not the kind of MVC
> you need. Swings is generic and geared towards
> display.
> (...) Your model layer should have no references to any sort of
> displaying of data.
I fully support this opinion.
A few years ago I suggested an RFE on the JDC's bug parade, to extract such DataModel classes out of Swing (e.g. in java.util, as an addition to the collections or whatever).
I think there's a backwards-compatible way to design this.
The advantage would be that applicative data model could be written independantly of Swing interfaces. Swing classes would simply have to provide wrappers around generic data model classes.
I had several times a need for this, I even rose this topic on public forums, but didn't get much support, and the RFE didn't even get listed :-(
I guess people find it more confortable to write their own data model classes, and write custom wrappers (e.g. MyXxxTreeModel) for Swing, but I find this last step has low added value.
So you have Surveys and Organizations as models and SurveyView and OrganizationView as views? I think this is incorrect.
You should start with your two view types. ViewStyle1 and ViewStyle2. Survey and Organization should be displayable by both view styles. Perhaps one is unsightly with a certain model, but thats beside the point.
If survey and organization have truly different display requirements then perhaps these classes can not be part of the same MVC structure. Sure you can force it to fit, but it will just blow up in massive number of classes.
