|
Replies:
21
-
Last Post:
Oct 25, 2007 5:58 AM
by: mrmorris
|
|
|
|
|
|
|
Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 6:08 AM
|
|
|
How come TreeTableNode defines the method getColumnCount? In old days, I used to populate my TreeTableModel with TreeNode derivatives that did not require this method to be implemented.
The problem is that my application has several JXTreeTable views and TreeTableModels, but they can't readily share my nodes because at the node level, there is no knowledge of however many columns a particular TreeTableModel is set to display.
What I do is to just set the count to the max required, it does not seem to have a negative effect on other views even if they have fewer columns. Of course this screams for me to abstract this out of the way altogether - especially since it doesn't even seem to be there to satisfy JTable semantics, because the only supertype for TreeTableNode is a TreeNode.
Just curious,
/Casper
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 6:26 AM
in response to: mrmorris
|
|
|
> How come TreeTableNode defines the method
> getColumnCount? In old days, I used to populate my
> TreeTableModel with TreeNode derivatives that did not
> require this method to be implemented.
This is a newer method. It was added to allow DefaultTreeTableModel to access any TreeTableNode without fear of IndexOutOfBoundsExceptions.
> The problem is that my application has several
> JXTreeTable views and TreeTableModels, but they can't
> readily share my nodes because at the node level,
> there is no knowledge of however many columns a
> particular TreeTableModel is set to display.
The model only uses them to ensure that there is valid data to query.
The DefaultTreeTableModel queries a node about it's columns before attempting to access a column. This way the nodes in your model can contain differing column counts and the Model handles them fine (by returning null).
Consider the following display:
RootNode extends AbstractMutableTreeTableNode, 8 columns (number shown by model, unless columnIdentifiers is populated)
FileNode extends AbstractMutableTreeTableNode, 4 columns
FileDetailsNode extends FileNode, 8 columns
This also means that you can place the FileDetailsNode in a six-column table; you'll just never see the last two columns.
At each level you can choose inform the Model how many columns you have to display data. The Model uses that information to query the node only for valid values.
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 7:15 AM
in response to: kschaefe
|
|
|
Ah I see, because of the general delegation going on from TreeTableModel to TreeTableNode. I had most logic placed in TreeTableModel overrides (getValueAt, getColumnCount...) thus I ended up with unused yet contractual methods at the node level.
Thanks for clarifying,
/Casper
[Edit]
Hmm seems to me if I refactor to use more delegation like that of DefaultTreeTableModel, the TreeTableNodes becomes even more dependent of the views (needs to know how to map to a specific model) so I guess in a node reusability scenario (which I am in) you'll always want to override and handle the mapping in the model - thus ending up with compiler satisfying dummy implementations of getValueAt and getColumnCount at the node level. I've come full circle, as it was the getColumnCount annoyance which spawned this thread in the first place. 
[/Edit]
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 8:07 AM
in response to: mrmorris
|
|
|
> Hmm seems to me if I refactor to use more delegation
> like that of DefaultTreeTableModel, the
> TreeTableNodes becomes even more dependent of the
> views (needs to know how to map to a specific model)
> so I guess in a node reusability scenario (which I am
> in) you'll always want to override and handle the
> mapping in the model - thus ending up with compiler
> satisfying dummy implementations of getValueAt and
> getColumnCount at the node level. I've come full
> circle, as it was the getColumnCount annoyance which
> spawned this thread in the first place.
I guess I don't understand what you mean. You can reuse a node class in more than one model. Can you explain what you're problem is in doing so?
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 8:22 AM
in response to: kschaefe
|
|
|
> I guess I don't understand what you mean. You can
> reuse a node class in more than one model. Can you
> explain what you're problem is in doing so?
I can sure try. If my nodes needs to be aware of column count and handle the mapping of a given column index to a value, it appears to me that there's a lot of responsibility and semanics burned in. For instance, you can not have a node handle getValueAt differently depending of whether it was called by a model that should display some parts of a node (say filename and size) while another model shows other parts (say filename and MD5).
So what I end up doing, is let the model handle this mapping (the model has to know about the column headers anyway) directly in the TreeTableModel.getValueAt rather than delegating to the nodes. That leaves my nodes be nothing more than - nodes in a tree.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 8:47 AM
in response to: mrmorris
|
|
|
I tend to work better with examples, so let's try this:
You have a node, call it FileNode:
FileNode maps the following columns {
0 = Name
1 = Size
2 = Modification date
3 = MD5 checksum
}
And you have two models:
Model1 has two columns: Name and Size
Model2 has two columns: Name and MD5
So, getValueAt(0, 1) on Model 1 should return name and size and on model 2 should return name and MD5. The boggle is that MD5 is actually 3 in the node.
I think I got that correct.
So, in your getValueAt for Model2, you end up doing:
if (node instanceof FileNode && columnIndex == 1) {
columnIndex = 3;
}
Is that so?
Here's a quicky proposal for altering the DefaultTreeTableModel to assist with this problem:
public Object getValueAt(Object node, int column) {
if (!isValidTreeTableNode(node)) {
throw new IllegalArgumentException(
"node must be a valid node managed by this model");
}
if (column < 0 || column >= getColumnCount()) {
throw new IllegalArgumentException("column must be a valid index");
}
TreeTableNode ttn = (TreeTableNode) node;
if (column >= ttn.getColumnCount()) {
return null;
}
return ttn.getValueAt(translateColumnPosition(ttn.getClass(), column));
}
protected int translateColumnPosition(Class<? extends TreeTableNode> node, int initialIndex) {
return initialIndex;
}
This would allow subclasses to take full advantage of all the prebuilt goodness in DefaultTreeTableModel and reuse nodes across any model.
Consider the following version for the example Model2 (from above):
protected int translateColumnPosition(Class<? extends TreeTableNode> node, int initialIndex) {
if (node instanceof FileNode && inititialIndex == 1) {
return 3;
}
return super.translateColumnPosition(node, initialIndex);
}
Thoughts?
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 8:56 AM
in response to: kschaefe
|
|
|
Code fix and clarity.
public Object getValueAt(Object node, int column) {
if (!isValidTreeTableNode(node)) {
throw new IllegalArgumentException(
"node must be a valid node managed by this model");
}
if (column < 0 || column >= getColumnCount()) {
throw new IllegalArgumentException("column must be a valid index");
}
TreeTableNode ttn = (TreeTableNode) node;
int newIndex = translateColumnPosition(ttn, column);
if (newIndex == -1) {
return null;
}
return ttn.getValueAt(newIndex);
}
protected int translateColumnPosition(TreeTableNode node, int initialIndex) {
if (column >= ttn.getColumnCount()) {
return -1;
}
return initialIndex;
}
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 10:28 AM
in response to: kschaefe
|
|
|
Ah well yes if you add a generic translation layer, that would assist in making a node hierachy more reusable up front.
However, for people relying on their own AbstractTreeTableModel derivative, I am still not sure what the bennifit is from introducing an indexing aspect all the way down at the TreeTableNode level. It may not be taking polymorphism to the limit, but since I am required to handle getColumnCount, getValueAt (and most will also handle getColumnName) in the model, placing column mapping logic here as well has the advantage of my application model nodes remaining "column neutral". (I am of course talking about a node hierachy more customized and richer than what a DefaultMutableTreeTableNode and its UserObject can represent.)
I.e. one could imagine a transient column (day span between two date fields) that I really don't want to incorporate directly into the nodes - being mainly a presentation thing. As you can tell, I find it hard to balance what to place in the model, what to place in the nodes and what to let renderers deal with. But I'll give your translation idea a go.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 11:09 AM
in response to: mrmorris
|
|
|
> Ah well yes if you add a generic translation layer,
> that would assist in making a node hierachy more
> reusable up front.
OK.
> However, for people relying on their own
> AbstractTreeTableModel derivative, I am still not
> sure what the bennifit is from introducing an
> indexing aspect all the way down at the TreeTableNode
> level. It may not be taking polymorphism to the
> limit, but since I am required to handle
> getColumnCount, getValueAt (and most will also handle
> getColumnName) in the model, placing column mapping
> logic here as well has the advantage of my
> application model nodes remaining "column neutral".
TreeTableNode are designed to be used with the DefaultTreeTableModel. Extending AbstractTreeTableModel to support TreeTableNodes is a lot of extra work. If there are some missing features in DefaultTreeTableModel, please let me know. AbstractTreeTableModel exists for easing development of non-node-based models, such as the FileSystemModel. What reason do you have for using the AbstactTreeTableModel as opposed to the DefaultTreeTableModel?
If getColumnName were not used by the view that would be wonderful. Unfortunately, the TableModel pollution is here as well to keep the tree table close to the table. You touch upon a valid point, perhaps if we use it as an identifier the translation mechanism could return a String and pass that to child node. Hmm, interesting, but I'm not convinced just yet. Let me think on that.
> I.e. one could imagine a transient column (day span
> between two date fields) that I really don't want to
> incorporate directly into the nodes - being mainly a
> presentation thing. As you can tell, I find it hard
> to balance what to place in the model, what to place
> in the nodes and what to let renderers deal with. But
> I'll give your translation idea a go.
Yeah, I'll wait for a little more feedback, but I kind of like the idea. Probably try to get it into the DefaultTreeTableModel soon if others like it.
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 1:23 PM
in response to: kschaefe
|
|
|
> FileSystemModel. What reason do you have for using
> the AbstactTreeTableModel as opposed to the
> DefaultTreeTableModel?
Good question, it just sorta got that way from reading the threads and the FileSystemModel example. One reason why I can not readily move to a DefaultTreeTableModel now is that my application model (nodes) works by adding nodes upon nodes and events traveling up and down the hierachy. I rather like having my nodes be unaware of any TreeTableModel (only my root node knows the model and can fire events to it) so I am not sure its worth the trouble moving to the Default... (I tried, which resulted in this thread: http://forums.java.net/jive/thread.jspa?threadID=31956&tstart=0 ...and which also taught me to ALWAYS do major surgery in a dedicated SVN branch
> If getColumnName were not used by the view that would
> be wonderful. Unfortunately, the TableModel
> pollution is here as well to keep the tree table
> close to the table. You touch upon a valid point,
> perhaps if we use it as an identifier the translation
> mechanism could return a String and pass that to
> child node. Hmm, interesting, but I'm not convinced
> just yet. Let me think on that.
Ok, sounds interesting though!
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 23, 2007 9:23 PM
in response to: kschaefe
|
|
|
> > Ah well yes if you add a generic translation
> layer,
> > that would assist in making a node hierachy more
> > reusable up front.
> OK.
At first glance, I thought this was a good idea. I have an array of (data) column
names in my nodes, in the order in which they display in the table.
(This allows all my nodes to be the same, just different arrays; it also makes it easy to get column count - just size of array )
If that could be extracted to an intermediary attached to the model it would put it
all in one place.
However, the problem, in my case, where all nodes are the same class, just different data, I would have to know at which level of the tree I am at.
Thought for the day: The only object that really knows it's children is the node.
If you move processing back to the model, you get a lot of
"if (node instanceof someNodeClass) statements, which I personally do
not like.
>
> > I.e. one could imagine a transient column (day
> span
> > between two date fields) that I really don't want
> to
> > incorporate directly into the nodes - being mainly
> a
> > presentation thing. As you can tell, I find it
> hard
> > to balance what to place in the model, what to
> place
> > in the nodes and what to let renderers deal with.
> But
> > I'll give your translation idea a go.
> Yeah, I'll wait for a little more feedback, but I
> kind of like the idea. Probably try to get it into
> the DefaultTreeTableModel soon if others like it.
>
> Karl
This is interesting.
My first thought is still it should be in the node, but the node may not have
all the data available.
I still have the problem of knowing at which level of the tree this applies.
I must add that, as all my nodes are the same class, just different data, I have
had to add a level field to the nodes, to facilitate processing outside of the
treetable.
(I could have used " if (getUserObject() instanceof ?class) but I thought level was easier. It also assists me in creating the nodes)
This of course, negates all my above arguments 
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 4:57 AM
in response to: rturnbull
|
|
|
> If you move processing back to the model, you get a
> lot of
> "if (node instanceof someNodeClass) statements, which
> I personally do
> not like.
I agree, it just leaves a bad taste in the mouth and screams for polymorphism. However, I don't see any other way of doing it - I really like having only the model care about column count and mapping. What I end up doing to remidy this, is to wrap the node in a container object. This also solved another problem I had, which is how to highlight an entire row based on node conditions - something that would require each column can access the same backing node. It does not get away with instanceof checking, but it encapsulates it a column level.
public Object getValueAt(Object node, int column)
{
switch(column)
{
case 0: // TreeTableNode column
return node;
case 1: // Color column
return new ColorColumn(node);
default:
throw new RuntimeException("TreeTableModel.getValueAt asked to address a column it is not suppose to contain!");
}
}
...my custom ColorColumn implements a TreeTableNodeColumn container:
public interface TreeTableNodeColumn
{
public MyTreeTableNodeSubclass getNode();
}
...and my highlighter can deal with both the raw node and the container:
protected boolean test(ComponentAdapter adapter)
{
Object value = adapter.getValue();
MyTreeTableNodeSubclass node;
// Handle is-a relations
if(value instanceof MyTreeTableNodeSubclass)
node = (MyTreeTableNodeSubclass)value;
// Handle has-a relations
if(value instanceof TreeTableNodeColumn)
node = ((TreeTableNodeColumn)value).getNode();
return node.isValidDateRange();
}
Donno if it makes sence to anyone else but me.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 5:36 AM
in response to: mrmorris
|
|
|
> > If you move processing back to the model, you get
> a
> > lot of
> > "if (node instanceof someNodeClass) statements,
> which
> > I personally do
> > not like.
>
> I agree, it just leaves a bad taste in the mouth and
> screams for polymorphism. However, I don't see any
> other way of doing it - I really like having only the
> model care about column count and mapping. What I end
> up doing to remidy this, is to wrap the node in a
> container object. This also solved another problem I
> had, which is how to highlight an entire row based on
> node conditions - something that would require each
> column can access the same backing node. It does not
> get away with instanceof checking, but it
> encapsulates it a column level.
I'd love to hear some better solution, but you're not limited to instanceof checking. You could do any custom node checking that you like. Anything to differentiate your nodes is fine. Depth in the model, column count of the node, whatever. The problem is that when translating from the model index to the node index, you have to, at some point, differentiate nodes to ensure that the correct data is displayed. That could mean never differentiating (all nodes column 1 actually maps to 3), or checking node type, user object type, depth, column count, etc. It's as polymorphic as you can make it, since the translation implementor will have to determine how to do the translation. I'm not advocating instanceof checks, but since most of the node-based models I used had different node types, it seemed natural to me.
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 6:37 AM
in response to: mrmorris
|
|
|
Casper,
hmm ... apart from the main theme of this thread - I still don't get
what exactly you are trying to do and why you try it the way you do.
Could you show a small (need not be runnable) code example of what you
did earlier (in the days before the TreeTableNode) and how you moved
that to the current way of SwingX? Basically, there's nothing which
prevents you from keeping TreeNodes and implement a custom
TreeTableModel inheriting from DefaultTreeModel. No magic involved -
only maybe I'm missing the point <g>
BTW, to format code for the forum you have to surround it with [ code ]
... [ /code ] tags (removin the spaces inside the brackets, obviously
Another thing I don't understand is how your container TreeTableNode is
supposed to solve the all-row highlighting. Anyway, your snippet looks
like you are still using the ConditionalHighlighter? If so, beware: it's
deprecated and definitely will be removed in one of the coming releases!
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 8:17 AM
in response to: Kleopatra
|
|
|
> Could you show a small (need not be runnable) code
> example of what you
> did earlier (in the days before the TreeTableNode)
> and how you moved
> that to the current way of SwingX?
I hardly remember, but it was all based on SwingX 0.6 and the FileSystem example.
This meant though, that I grew into being able to simply add a node to a node, without the model being involved. Only my root node would know about (hold a reference to) the model, and through the events I have flowing up and down the hierachy, the root is able to determine whether an event should fire off the model (to update any view part). If I switch to DefaultTreeTableModel now, nothing renders... probably because I need to build through DefaultTreeTableModel.insertNodeInto() instead of TreeTableNode.add(). Using the DefaultTreeTableModel seems to be highly recommeded by both you and Karl, so I would love to do that... only I have bosses who couldn't care less about how things are done as long as the software works and is on time. *sigh*
> Another thing I don't understand is how your
> container TreeTableNode is
> supposed to solve the all-row highlighting.
ComponentAdapter can only see the current cell component, that's fine when the actual cell component is a node in my tree such that I can perform the conditional checking - but if it is just a plain integer there's no way for me to access the node to which it belongs.
> If so, beware: it's
> deprecated and definitely will be removed in one of
> the coming releases!
I know, its on my todo to rewrite it... though the docs does not mention what the highlighter has been deprecated by?!
And thanks for the code formating tip, I searched the Java.net FAQ in vain for that.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 9:23 AM
in response to: mrmorris
|
|
|
> ComponentAdapter can only see the current cell
> component, that's fine when the actual cell component
> is a node in my tree such that I can perform the
> conditional checking - but if it is just a plain
> integer there's no way for me to access the node to
> which it belongs.
Don't forget that the adapter does provide a good deal of context, such as depth in the tree.
I, too, have had an issue with need to attach additional metadata to the Adapter. We have a collection of entries and those entries have validation results. The table displays properties of the entry, but the highlighter needs to know about the validation results to set borders correctly. I didn't make the first go round on that code, so it was implemented using core renderers. However, there seems to be a missing piece here. I should have to be required to extend JXTreeTable to be able to extend TreeTableDataAdapter to add custom metadata.
Anyway, that's a little off-topic. If there is extra context information that would be useful for the general Adapter, let us know.
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 5:25 AM
in response to: rturnbull
|
|
|
Some good point in there, which give me a couple of thoughts. Does TreeTableNode need a getDepth()? Interesting idea to include it, but that would be problematic. There is no definitition of root other than the node which was assigned as the root for the model. Theorectically, you could have a very large tree that contained many levels and for a particular tree table only display a certain branch of data. That means that the "root" actually has a parent. A getDepth() would also require an isRoot/setRoot flag to determine your depth from the closest root. But that could lead to troubles if the larger model is used simultaneously elsewhere. Not sure if any of that really has a point, but I thought that I'd get my thoughts on paper.
The general case (ie, what we need to do in SwingX) and the specific are often different. If your nodes are designed to be part of only one model that can't have subtree used in other models, then getDepth is easier. Of course, there's nothing restricting how a user could implement translateColumnIndex, so custom nodes could use custom methods, such as getDepth.
Hmm, perhaps the model should have a protected getDepth(TreeTableNode node) that walks the tree until it reaches the root. The model really knows where the node is, the node itself doesn't really care. This would be similar to the isValidNode method in several of the models that I created. It would also keep that type of data out of the node, which could possibly be used simultaneously in two models: one with the "true" root and one with a subtree root.
Karl
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 7:51 PM
in response to: kschaefe
|
|
|
> Some good point in there, which give me a couple of
> thoughts. Does TreeTableNode need a getDepth()?
> Interesting idea to include it, but that would be
> problematic. There is no definitition of root other
> than the node which was assigned as the root for the
> model. Theorectically, you could have a very large
> tree that contained many levels and for a particular
> tree table only display a certain branch of data.
> That means that the "root" actually has a parent.
> A getDepth() would also require an isRoot/setRoot
> flag to determine your depth from the closest root.
> But that could lead to troubles if the larger model
> is used simultaneously elsewhere. Not sure if any
> of that really has a point, but I thought that I'd
> get my thoughts on paper.
>
Amazing. It never occurred to me that the root node could actually have a
parent.
> Hmm, perhaps the model should have a protected
> getDepth(TreeTableNode node) that walks the tree
> until it reaches the root. The model really knows
> where the node is, the node itself doesn't really
> care. This would be similar to the isValidNode
> method in several of the models that I created. It
> would also keep that type of data out of the node,
> which could possibly be used simultaneously in two
> models: one with the "true" root and one with a
> subtree root.
>
> Karl
I like this. But why 'protected'. Please make it public.
It should be easy.
Would this fit:
public int getDepth(node) {
return getPathToRoot(node).length - 1;
}
Perhaps it's so easy it's hardly worth doing.
(by the way, I think you should add an 'isValidNode()' to
getPathToRoot().)
However I tend to agree with Kleopatra, we should not try and make
DefaultTreeTableModel cover every alternative.
It should be easy enough to extend it and override getValueAt for more complex
cases.
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 25, 2007 5:18 AM
in response to: rturnbull
|
|
|
The main reason for starting this thread was that for people working with more advanced node hierachies (i.e. not just one view and probably not using the Default... stuff) it would be nice if column semantics was left out of the TreeTableNode and was perhaps only introduced in DefaultMutableTreeTableNode (which is a convenience level as I understand). Perhaps this simply breaks the overall design so it can't be done, but I would imagine more than just I ending up with dummy implementations of getColumnCount and getValueAt in their nodes to satisfy the current TreeTableNode contract.
I'm but a mortal user, so perhaps I am being overly naive or doesn't fully understand the importance of having column semantics in place at the node level. But considering how commonplace master-detail views are (have a look at the NetBeans API), I find it ironic that a getDepth at the node level is *too specific* while getColumnCount and getValueAt (which forces you to deal with view semantics right there in your application model) apparently isn't.
I liked the translation idea, at least it would make it apparent that its a *virtual column* and not nessesarily have anything to do with how these display in a JXTreeTable - DefaultTreeTableModel could provide a n:n default mapping while the more demanding user is free to override this mapping to his liking.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 25, 2007 5:24 AM
in response to: mrmorris
|
|
|
Casper,
> For people working with more advanced node hierachies (i.e. not just one view and probably not using the Default... stuff) it would be nice if column semantics was left out of the TreeTableNode and was perhaps only introduced in
the whole design purpose of the TreeTableNode is to _have_ the column
semantics. If you don't want them on that level, use a plain TreeNode
instead (plus a custom DefaultTreeModel - note the omission of "Table" -
which implements the column semantics).
> DefaultMutableTreeTableNode (which is a convenience level as I understand). Perhaps this simply breaks the overall design so it can't be done, but I would imagine more than just I ending up with dummy implementations of getColumnCount and getValueAt in their nodes to satisfy the current TreeTableNode contract.
>
you know better than to implement dummies <g>
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 25, 2007 5:53 AM
in response to: Kleopatra
|
|
|
> the whole design purpose of the TreeTableNode is to
> _have_ the column
> semantics. If you don't want them on that level, use
> a plain TreeNode
> instead (plus a custom DefaultTreeModel - note the
> omission of "Table" -
> which implements the column semantics).
Right, good point. I rest my case.
> you know better than to implement dummies <g>
I guess not, UnsupportedOperationException is thrown in many adaptor classes. But it is ugly yeah.
/Casper
|
|
|
|
|
|
|
|
|
Re: Purpose of TreeTableNode.getColumnCount(...) ?
Posted:
Oct 24, 2007 6:23 AM
in response to: kschaefe
|
|
|
Interesting discussion ... jumping in at an arbitrary point with a
couple of comments (no contradiction intended
- I think part of the "problem" is the fact that an integer is a weak
identifier. Nevertheless, that is what a J/X/Table relies on, both for
columns and rows. No way around and no prospects of doing so in any
overseeable time plan.
- DefaultTreeTableModel/TreeTableNode are highly focused (at least
that's my pov) on a simply use-case: nodes which are similar enough and
simple enough to be handled rather uniformly. If custom nodes and/or
model scenarios differ from this simplicity, it's time for going custom
model. I would not try to overstuff the DefaultTTM, not even with some
kind of index-mapping.
- We could experiment with TTN alternatives, with an api which allows
column access via "real" identifiers. Then the model would be
responsible to map those identifier to column indices. At the end of
experiments, we could probably extract a more useful DefaultXModel, or
not, don't know <g> Tree structures tend to be unwieldy and come in too
many variations for a useful generalization.
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
java.net RSS
