Naming of view components
I'm trying to implement an application using a fairly typical MVC architecture. Basically I have a number of classes which represent my data, a variety of interfaces (such as tree interfaces, recordset interfaces) which some or all of my data classes implement, and a variety of UI components which are able to view/edit objects which implement certain interfaces. I've run into a bit of a conceptual problem with exactly what the contract of my view components should be. At present I've given them names like TreeModelView and RecordModelView. However, I want to implement a number of different components which view objects of type ITreeModel in different ways. Maybe I should give them names like EditableTreeView, GridView etc to reflect the way in which they are viewed rather than what they view. Any general advice/pointers to information about this would be greatly appreciated!
[897 byte] By [
alexflinta] at [2007-10-1 22:55:18]
> However, I want to implement a number of different
> components which view objects of type ITreeModel in
> different ways. Maybe I should give them names like
> EditableTreeView, GridView etc to reflect the way in
> which they are viewed rather than what they view. Any
> general advice/pointers to information about this
> would be greatly appreciated!
Sounds good enough to me. I mean, that's what's the difference between those components, isn't it? And since you're separating view and model anyway, you could theoretically use a table model and display it as a tree if you want to. The important part about that component is that it shows a tree, not that it gets its data from a table or any other model. If you draw a line between View and Model, why would you want to keep the model in the component's name?
> And since you're separating view and model anyway, you could theoretically use a table model and display it as a tree if you want to
Not sure what you mean by this....
If I was writing a Tree View, I'd do what is done with Swing and have it knowing a Tree Model. I wouldn't try having the view being able to deal with several model types.
If I wanted a Tree View to display a Table Model, I'd write a TreeModel implementation which adapted a TableModel in to some form of tree (for however that made sense for the application...).
In either case, the Tree View would still only ever talk to a Tree Model.
> If I wanted a Tree View to display a Table Model, I'd
> write a TreeModel implementation which adapted a
> TableModel in to some form of tree (for however that
> made sense for the application...).
Imagine you have a table like this:
?--?--?--?--
A ?1 ?1 ?1 | 1
A ?1 ?1 ?1 | 2
A ?1 ?1 ?2 | 1
A ?1 ?2 ?1 | 1
And so forth. It's a table, alright, but isn't it better presented as a tree?
A
+-1
?+-1
? +-1
?+-1
?+-2
? +-2
?+-1
?+-2
+-2
+-1
The view is responsible for showing a tree. The model can still be a table. Or the other way around. You need a transformation, but since the transformation is for "optical" purposes only, I think the view needs to do it, instead of creating a whole new and completely redundant tree data model. So the class should be a SomethingTreeView, and not a SomethingTableModelView. That wouldn't give you any info about what would appear on the screen - which is the important part.
Surely you need the view to be able to understand the model, but when it comes back to naming the view's class, I think it shouldn't have the name of the model, rather than the name of its appearance.
> I think the view needs to do it, instead of creating a whole new and completely redundant tree data model.
I disagree. But thats probably mostly because most of the forums are still broken, and I'd probably disagree with anything right now just to get some decent conversation round here :o)
Writing a good "view" component is a fairly complicated business - and if I've got a Tree view that knows how to display a Tree based on an underlying model, then I dont want to have to change my view just because I want to display a table in tree form.
What if next week I'd like to warp a "graph" model in the same way to look like a tree?
In both cases, I'd like to be able to re-use my existing view.
So, how can I reuse my view if it only talks TreeModels?
Well, the adaptor pattern comes in handy here.
Its fairly easy to write a "WhateverTableModelAdaptor" implementation of TreeModel which delegates to the existing underlying TableModel, but presents the data in the tree form you have shown above.
That way, we can simply "plug in" our TableModel to a Tree view by wrapping it in our shiny new "WhateverTableModelAdaptor".
It also means I dont have to get my hands dirty writting a whole new view component - which with my shoddy Swing skills is a Good Thing.
> I think the view needs to do it, instead of creating a whole new and completely redundant tree data model
Just to be clear, I am suggesting writing an adaptor which delegates to an underlying table model - applying whatever tricks it needs to make it appear like a tree model as desired.
So we dont copy all the existing model data in to a new DefaultTreeModel (or what-ever).
I think in this case the model adaptor code would probably be significantly easier to implement than writing a new view to make a TableModel look like a tree.
Forgive me if I'm mistaken, but: the OP asks how to name his custon view classes. I say it's the view and not the model, so keep the latter out of it.
Sorry - didn't mean to offend. I was simply addressing points which you yourself raised.
> Sorry - didn't mean to offend.
> I was simply addressing points which you yourself
> raised.
I'm not offended at all. I just raised the points because I understood that the OP might want to provide views not exactly matching the model, to use those as an argument. If the OP really creates a tree view for a table, then the view-model link is really weak (even more so with your adaptors) , and should not be mentioned in the class's name as it could actually change (I'd be surprised if he creates a tree view that can show table models, but not tree models) and it's not the info we are usually looking for when wanting to know what the class does.
I completely agree :o)
I should have qualified my post stating that I wasn't addressing the OPs question.
I was only addressing your interesting points about providing a tree view for an underlying table model: and still stand by the fact that showing a TableModel (for example) in a JTree (for example) would be significantly easier to achieve by providing an adaptor than by writing (/updating) a new (/existing) view component.
> I completely agree :o)
>
> I should have qualified my post stating that I wasn't
> addressing the OPs question.
> I was only addressing your interesting points about
> providing a tree view for an underlying table model:
> and still stand by the fact that showing a TableModel
> (for example) in a JTree (for example) would be
> significantly easier to achieve by providing an
> adaptor than by writing (/updating) a new (/existing)
> view component.
Yepp. :)
Thanks very much for all your help here! I agree that it is more appropriate for the name of a view component to reflect what it displays, not the model that it draws data from. Thanks again!
