Skip to main content

JXTreeTable access widening exercise results

35 replies [Last post]
ovisvana
Offline
Joined: 2005-07-29

Hi Jeannette,
I have completed the work relating to the access restrictions on some classes and methods in the swingx library. I made the bare minimal changes to swingx code as you suggested in order for my JXmlTreetable to compile and run and the results are as follows:

1. The TreetableDataAdapter class inside JXTreeTable and its constructor
2. The TreetableModelAdapter class inside JXTreeTable and its constructor (not used by me)
3. The TreeTableCellRenderer class inside JXTreeTable
4. The initActionsAndBindings method in JXTable
5. The init(renderer) method in JXTreeTable
6. The Actions inner class in JXTreeTable and corresponding constructor
7. The initActions method in JXTreeTable
8. The 'public boolean consumedOnPress' variable
9. The 'public TreeTableHacker treeTableHacker' variable

The above classes and methods have to be marked public if they are to be usable from outside the package. I would appreciate if you could please make the above changes to swingx code so no fork would be necessary in my JXmlTreeTable component based on swingx.

I look forward to your comments.

cheers,
ovisvana
http://ovisvana.blogspot.com

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kleopatra

>
> I am very interested in reading your article, since I think it will inform the discussion about the access level of the Adapter. I know that I view the tree table as a "tree" first and foremost (and I think Jeanette is the same way).

Well, my view evolved a bit - for pragmatic reasons: seeing it as
kind-of tree helped a lot to make things work. My first and far-future
view of it is that the model is both, which would make the adapter
obsolete. There were some discussions about that direction last summer
(?) but dropped it because the task was just too big a step at one time.

> I am curious as to what problems you had encountered that caused you to need override the Adapter. So, please email a copy of the article (if you're willing) and I'll give it a read.
>

count me on that as well, Prakash, mail me the article if you like.
>
> Jeanette, I think that we should collect the various model implementations that we used a lot for testing and what not into a collected area (either the treetable subpackage, or a treatable.models subpackage). I think that having these models collected and distributed will be important for getting users to work with the tree table.
>

good idea to have a collection of model implementations - but where? Not
sure if main swingx is the right place. Hmm ... yet another candidate
for inclusion into the hypothetical optional source tree ;-) Maybe we
could have a "common" section in the incubator?

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

> >
> > I am very interested in reading your article, since
> I think it will inform the discussion about the
> access level of the Adapter. I know that I view the
> tree table as a "tree" first and foremost (and I
> think Jeanette is the same way).
>
> Well, my view evolved a bit - for pragmatic reasons:
> seeing it as
> kind-of tree helped a lot to make things work. My
> first and far-future
> view of it is that the model is both, which would
> make the adapter
> obsolete. There were some discussions about that
> direction last summer
> (?) but dropped it because the task was just too big
> a step at one time.
Link please. I have a terrible time using the search on this site.

Karl

ovisvana
Offline
Joined: 2005-07-29

Hi Jeanette/Karl,
I have sent you both an email along with my article. Please go through and send me your comments/suggestions.

cheers,
prakash

kschaefe
Offline
Joined: 2006-06-08

> Ultimately I would like to get the XmlTreeTable
> working without forking swingx. If that can be
> achieved by keeping the adapter as inner class, Iam
> okay with it. I would appreciate if you could take a
> look at the other items I had mentioned as needing
> change such as the initActions,
> initActionsAndBindings etc.
Sure, it's already protected so we're good there. I was commenting with the inclusion of my (very simple) XmlTreeTableModel that I think you may be trying to do work in the wrong area. Even though the JXTreeTable extends JXTable, it really is a tree. Most of the work should be performed on the tree side of things, such as inserting and deleting nodes. Although I have had an idea about how we can create mutable adapters.

If we create a MutableTreeTableModel that add insert and delete operations, we could create a MutableTreeTableModelAdapter, which could specify its own insert and delete operations from the table view, passing them back into the tree model. Such additions would allow developers to create mutability from either end of the JXTreeTable. The problem is that I think it's more work that it may be worth.

I'll poke my head into some other parts of your code, but I'm currently working to tie up loose ends before I head to JavaOne, so I may not have some comments for a few days.

Karl

ovisvana
Offline
Joined: 2005-07-29

>Even though the JXTreeTable extends JXTable, it really is a tree.
I have come to understand that much from what's been discussed on this forum and also from my work.

>If we create a MutableTreeTableModel that add insert and delete operations, we could create a MutableTreeTableModelAdapter ...
Thats your design decision and probably overkill like you have said yourself.

I will let you know the results after making the adapter an inner class. I would like to if possible close it out before javaone so I can get my article published.

cheers,
ovisvana

evickroy
Offline
Joined: 2004-07-23

> BTW, my request to join the swingx project has been
> pending for a while now. Is anyone going to approve
> that or does this mean the end of the road.
>
> cheers,
> ovisvana

I wouldn't read too much into having no response back yet. Most, or all, of the project owners are busy with JavaOne preperations, so they probably haven't gotten around to responding to the project role requests. I'm not sure what you requested, but typically you would want Observer role so that you have access to the source and can submit issues and patches. Just no commit access. If you want to contribute code, then you should fax/email a signed copy of the JCA. After that is approved, you will have access to commit to the incubator.

Erik

kschaefe
Offline
Joined: 2006-06-08

I threw together a quickie XmlTreeTableModel. It is based on my incubator work so some methods may need to be implemented for the current SwingX code-base.

[code]package org.jdesktop.swingx.treetable;

import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

/**
*
*/
public class XmlTreeTableModel extends AbstractTreeTableModel {
public XmlTreeTableModel(Document doc) {
root = doc;
}

public Document getRoot() {
return (Document) root;
}
//
// public void setRoot(Document doc) {
// root = doc;
//
// //TODO fireChange
// }

/**
* {@inheritDoc}
*/
public int getColumnCount() {
return 1;
}

/**
* {@inheritDoc}
*/
public Object getValueAt(Object node, int column) {
//TODO better checking
if (!(node instanceof Node)) {
throw new IllegalArgumentException();
}

return ((Node) node).getNodeName();
}

/**
* {@inheritDoc}
*/
public Object getChild(Object parent, int index) {
//TODO better checking
if (!(parent instanceof Node)) {
throw new IllegalArgumentException();
}

return ((Node) parent).getChildNodes().item(index);
}

/**
* {@inheritDoc}
*/
public int getChildCount(Object parent) {
//TODO better checking
if (!(parent instanceof Node)) {
throw new IllegalArgumentException();
}

return ((Node) parent).getChildNodes().getLength();
}

/**
* {@inheritDoc}
*/
public int getIndexOfChild(Object parent, Object child) {
//TODO better checking
if (!(parent instanceof Node)) {
throw new IllegalArgumentException();
}
if (!(child instanceof Node)) {
throw new IllegalArgumentException();
}

NodeList list = ((Node) parent).getChildNodes();

for (int i = 0, len = list.getLength(); i < len; i++) {
Node n = list.item(i);

if (n.isSameNode((Node) child)) {
return i;
}
}

return -1;
}
}[/code]
If you want to add mutability to the table add it to the TreeTableModel instance. The changes will display correctly in the table. This is why I believe that you do not need to override the TreeTableModelAdapter. Your model mutators should be on the TreeTableModel. So imagine above with addNode(Object parent, Object child), removeNode(Object node), etc. I think XML is a good example for JXTreeTable, so I will try to create a more full-featured model at some point.

Karl

ovisvana
Offline
Joined: 2005-07-29

Hi Karl,
Ultimately I would like to get the XmlTreeTable working without forking swingx. If that can be achieved by keeping the adapter as inner class, Iam okay with it. I would appreciate if you could take a look at the other items I had mentioned as needing change such as the initActions, initActionsAndBindings etc.

Erik,
You're probably right that Iam trying to read too much into not receiving a response. I will wait a while longer. I already have commit access to the JDNC-INCUBATOR. What I wanted was developer role in swingx project so I could commit stuff. Thanks anyway.

cheers,
ovisvana

kirillcool
Offline
Joined: 2004-11-17

> What I wanted was developer role in
> swingx project so I could commit stuff.

For such a role one usually needs to work pretty hard. This is what the incubator is for - so that the developers can see the perseverance, quality of your work etc.

kschaefe
Offline
Joined: 2006-06-08

I took a look at the action stuff:
> 4. The initActionsAndBindings method in JXTable
> 5. The init(renderer) method in JXTreeTable
> 6. The Actions inner class in JXTreeTable and
> corresponding constructor
> 7. The initActions method in JXTreeTable

In no particular order:
Actions inner class does not need to be extended. It is creating the actions useable by all JXTreeTables. Your JXmlTreeTable should keep the GridActions class, but instead of subclassing Actions, subclass UIAction. Also you should remove the remove-all, expand-all actions from GridActions, as these are configured for you in Actions.

No need to widen initActions either. JXTreeTables should be configured with the expand-all, remove-all actions by default. Widening initActions could lead to developer mistakes where the the overriding method fails to invoke super's version. If you need to add additional actions to the ActionMap, you can add them anywhere. If you'd like to follow the paradigm here, then have your own private method that adds your GridActions to the ActionMap, then do so. Your actions should be added and configured seperately, there is no need for JXTreeTable to provide access to configuring actions that it is trying to declare for all tree tables. If the expand-all/collapse-all actions are not in the map for your subclass, then this is a bug.

You're not doing anything with initActionsAndBindings, so why do you need access to it? It is being called during the constructor chaining when you create a JXmlTreeTable.

init(TreeTableCellRenderer) is not required to be more open if we utilize a protected constructor as I suggested before. Such as constructor would keep the implementation details private (ie the details of init(TTCR)) which should not vary for any tree table.

So, if you continue to believe that subclassing TreeTableModelAdapter is correct, (I do not believe that is the case, see my other posts), then what we really need is a protected constructor for the subclass to utilize.

This is obviously not the end-all-be-all discussion on these points, but my opinion about why we do not need to expand some of these members. If you have a compelling argument for the other case, please make it.

Karl

Kleopatra

Karl, I agree with your evalutions. As to the private vs. protected
constructor/adapter - the api is definitely inconsistent in having a
protected adapter class which is instantiated in a private constructor:
custom adapter classes cannot be injected anyway, so the adapter should
be private as well. If we really need the flexibility of a custom
adapter class your suggestion of a protected constructor taking the
adapter as param is good - though I personally prefer to have factory
methods for the same effect. Which here is not easily possible because
we don't allow a plain tableModel ... which is fishy in itself, but
that's another construction site ;-)

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

Thanks, Jeanette. Good to know that I was on target. From what I can tell, ovisvana's extension of the adapter was to add mutating abilities to the tree table. I believe that this should be done via the TreeTableModel, but he seemed unconvinced. I think that we could create an adapter that was mutable and called the mutators on the TreeTableModel. The reason for this, some people are clearly more in tune working with the table-side of things as opposed to the tree side. This probably has to do with the fact that the class extends JXTable and everyone's first thought is, "I've got to make a mutable table model."

I've gotten the TreeTableNode stuff done, sans unit tests. I hope to get some time during JavaOne (not that there's going to be a lot of down time this week) to write them. Once I have everything in and tested, I'll let you know.

Also, I've started mentally putting together a list of dos and don'ts in my head that are forming a tutorial. I think I will try to write something up for the JXTreeTable after the TreeTableNode release.

Karl

ovisvana
Offline
Joined: 2005-07-29

>ovisvana's extension of the adapter was to add mutating abilities to the tree table
That is not correct. While the finished adapter does have editing related functionality in it, the code I checked into the incubator and that I sent to you is devoid of any editing related code. The reason for the subclassing was different and had to do with displaying of XML in a grid like format.

>I believe that this should be done via the TreeTableModel, but he seemed unconvinced
I was only trying to argue why the adapter had to be protected. If the TreeTableModel has to be enhanced to add mutability to it, then so be it. I would like to see how you do this. Also I have made the SimpleTreeModelAdapter an inner class. I will post the results soon.

cheers,
ovisvana aka prakash
http://ovisvana.blogspot.com

kschaefe
Offline
Joined: 2006-06-08

> >ovisvana's extension of the adapter was to add
> mutating abilities to the tree table
> That is not correct. While the finished adapter does
> have editing related functionality in it, the code I
> checked into the incubator and that I sent to you is
> devoid of any editing related code. The reason for
> the subclassing was different and had to do with
> displaying of XML in a grid like format.
>
> >I believe that this should be done via the
> TreeTableModel, but he seemed unconvinced
> I was only trying to argue why the adapter had to be
> protected. If the TreeTableModel has to be enhanced
> to add mutability to it, then so be it. I would like
> to see how you do this. Also I have made the
> SimpleTreeModelAdapter an inner class. I will post
> the results soon.
I apologize for the misrepresentation of your code. My comments were from memory and were clearly incorrect. I recall (correctly or not) a version of your code that had such mutators.

I still would like to understand more why you are subclassing the adapter. I believe that everything the tree table is doing should be capable from the TreeTableModel. Taking a second look at your code, I can't really see the motivation for the adapter extension. Can you please explain what your goal is here?

Karl

ovisvana
Offline
Joined: 2005-07-29

> I can't really see the motivation for the adapter extension. Can you please explain what your goal is here:
Sure. As a matter of fact, it hasn't got anything to do with mutability or the model even though in the end it is the model that is queried for the data to be displayed. What Iam doing is building some meta-data by iterating over the XML DOM that tells the model what gets displayed in a table cell. I build this meta-data once at the start of the demo and again each time a node is expanded/collapsed. For this I trap the mouse event and retrieve the location of the mouse click and the event type and instruct the adapter to update its meta-data. Iam not sure if the treetable had access to all the required information and even if it did, that the adapter was so sacrosanct that it should not be subclassed :->.

Add to the above the mutator methods, the need for subclassing should be clear.

>I believe that everything the tree table is doing should be capable from the >TreeTableModel
I believe you are referring to the underlying model which in my case is the SimpleTreeModel when you refer to TreeTableModel. But as far as iam concerned the table accesses its model only through the adapter. e.g please refer to the following methods:

public int getColumnCount()
public String getColumnName(int column)
public Class getColumnClass(int column)
public int getRowCount()
protected Object nodeForRow(int row)
public Object getValueAt(int row, int column)
public boolean isCellEditable(int row, int column)
public void setValueAt(Object value, int row, int column)

If by your statement you mean that the table should directly talk to the model, then I would have to disagree.

Hope this makes things more clearer to you. comments welcome.

cheers,
prakash
http://ovisvana.blogspot.com

kschaefe
Offline
Joined: 2006-06-08

> > I can't really see the motivation for the adapter
> extension. Can you please explain what your goal is
> here:
> Sure. As a matter of fact, it hasn't got anything
> to do with mutability or the model even though in
> the end it is the model that is queried for the data
> to be displayed. What Iam doing is building some
> meta-data by iterating over the XML DOM that tells
> the model what gets displayed in a table cell. I
> build this meta-data once at the start of the demo
> and again each time a node is expanded/collapsed.
> For this I trap the mouse event and retrieve the
> location of the mouse click and the event type and
> instruct the adapter to update its meta-data. Iam
> not sure if the treetable had access to all the
> required information and even if it did, that the
> adapter was so sacrosanct that it should not be
> subclassed :->.
Why is it important to build the metadata here as opposed to the TreeTableModel? Can you give me an idea for the metadata that you're trying to capture? BTW, if some of this infringes on your article, we can move this discussion to email.

> Add to the above the mutator methods, the need for
> subclassing should be clear.
Possibly, but I think that there another way to tame that tiger.

> >I believe that everything the tree table is doing
> should be capable from the >TreeTableModel
> I believe you are referring to the underlying model
> which in my case is the SimpleTreeModel when you
> refer to TreeTableModel. But as far as iam concerned
> the table accesses its model only through the
> adapter. e.g please refer to the following methods:
>
> public int getColumnCount()
> public String getColumnName(int column)
> public Class getColumnClass(int column)
> public int getRowCount()
> protected Object nodeForRow(int row)
> public Object getValueAt(int row, int column)
> public boolean isCellEditable(int row, int column)
> public void setValueAt(Object value, int row, int
> column)
>
> If by your statement you mean that the table should
> directly talk to the model, then I would have to
> disagree.
The tree table is just a view of the model. Two simultaneous views of the same model, in fact. Theorectically, this means that you can play with the model via two ways: the controller for each view, which in this case is some selection/event listener that drives changes. So, what's the difference between mucking with the tree model vs the table model? It would seem more natural (to me) that if I needed to make a change to the model that I would choose the one that contains the data, which is the TreeTableModel (your SimpleTreeModel) and not the adapter that morphs the view to be compatible with another view. Perhaps, your metadata is informing this choice. What metadata are you capturing about a node? I tried to figure that out, but I saw a bunch of System.err.printlns where I expected to see metadata capture.

Karl

Kleopatra

Prakash,

one thing to keep in mind: the underlying model of the JXTreeTable is a
TreeTableModel, surprising as it is with the treeTable being a JXTable
and the treeTableModel being a TreeModel Another, that the
JXTreeTable is a kind of longstanding hack, which is planned (har, har
...we all know the lifetime of loved hacks ;) to be replaced by a more
clean re-write of the component.

The implication is that most things except the TreeTableModel should be
regarded as a kind of implementation detail - not strictly, because the
view needs tree-style and table-style api. But first and of all, the
TreeTableModel _is_ a TreeModel (misnomed, but couldn't convince Scott
to rename ...) and all model related stuff you want to survive in the
long run should be done in a custom TreeTableModel, the exact nature of
the adapter might change. Once you start thinking of the JXTreeTable as
a Tree disguised in Table clothes, the puzzle will start to fit - at
least that's my experience, being a Table aficionada to my bones :-)

HTH to clear some confusion
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

ovisvana
Offline
Joined: 2005-07-29

>Why is it important to build the metadata here as opposed to the TreeTableModel
Since the adapter conveniently groups all the objects required to perform this operation like the tree, the model etc.

>Why is it important to build the metadata here as opposed to the TreeTableModel? Can you give me an idea for the metadata that you're trying to capture? BTW, if some of this infringes on your article, we can move this discussion to email.
Not at all. But rather than go into the gory details here, I'll send you my article by email and you can review it. Iam supposed to get it peer reviewed before submitting it anyway.

Jeannette,
>Once you start thinking of the JXTreeTable as
a Tree disguised in Table clothes, the puzzle will start to fit
With all due respects, I think it is a bit demeaning to the treetable to reduce it to a tree when it is actaully a tree and a table. For example, in the below code,

[code]
public Object getValueAt(Object o, int column) {
if (column == 0) {
return o.toString();
}

return new Boolean(true);
}
[/code]

the model makes a check for the hierarchical column and returns a default value for all the other columns. So in a way, it is a model for both the tree and the table. This gets more complicated when you have a XML DOM as the model especially with the way I have implemented it.

All said and done, I don't think this impinges on my original request which was for access widening. I have followed your and Karl's suggestion and made my adapter an inner class. The constuctor in the super class needs to be made public though, plus the other items in my list. Since javaone has already begun, I guess this will have to wait until after that.

cheers,
ovisvana
http://www.omkaragifts.com

ovisvana
Offline
Joined: 2005-07-29

The final (hopefully) list of changes to swingx files needed to make my JXmlTreeTable component work without forking swingx is as follows:

1. The TreeTableModelAdapter(TreeTableModel model, JTree tree) constructor in TreeTableModelAdapter should be marked protected
2. The Actions class in JXTreeTable should be marked protected
3. initActionsAndBindings() method in JXTable should be marked protected
4. init(TreeTableCellRenderer renderer) method in JXTreeTable should be marked protected
5. initActions() method in JXTreeTable should be marked protected

I would be much grateful if someone could make the above changes or atleast give me a timeframe for when these changes would be commited. I look forward to your cooperation and help.

cheers.
prakash
http://www.omkaragifts.com

Kleopatra

Prakash,

> The final (hopefully) list of changes to swingx files needed to make my JXmlTreeTable component work without forking swingx is as follows:
>
> 1. The TreeTableModelAdapter(TreeTableModel model, JTree tree) constructor in TreeTableModelAdapter should be marked protected
> 2. The Actions class in JXTreeTable should be marked protected
> 3. initActionsAndBindings() method in JXTable should be marked protected
> 4. init(TreeTableCellRenderer renderer) method in JXTreeTable should be marked protected
> 5. initActions() method in JXTreeTable should be marked protected
>
> I would be much grateful if someone could make the above changes or atleast give me a timeframe for when these changes would be commited. I look forward to your cooperation and help.
>

the short version: no change -> no timeframe ;-) This applies for 2. to
5. I think Karl explained the whys quite clearly.

The open question is if/how to open up the access to the adapter. I'm
still unconvinced - having the adapter out in the open is old
(JTreeTable version 1 to 3) style, it was a conscious design decision to
hide it, so I think we need a good reason to paddle back again.

Open to discussion of course.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

ovisvana
Offline
Joined: 2005-07-29

Hi Jeannette,
I take it that there is no guarantee that these changes will be implemented any time soon or will be implemented at all. I feared this would happen from the outset. However, I can take some positives in that I learnt about why the adapter needs to be protected and not exposed and so on. But Iam not sure about what you mean Karl explaining things. Items 2-5 were never discussed and the discussion was for the most part centered around the adapter and why it needed protecting.
Iam not asking you to paddle back. In case you missed a thread in the middle, I have made my adapter an inner class and only ask you to make the constructor public leaving the class itself protected.

Iam winding up this discussion from my side and if somebody is willing to reopen it, thats fine with me.

cheers,
prakash

kschaefe
Offline
Joined: 2006-06-08

Prakash,

I did talk about those points earlier. You can search the thread for my response.

I am very interested in reading your article, since I think it will inform the discussion about the access level of the Adapter. I know that I view the tree table as a "tree" first and foremost (and I think Jeanette is the same way). I am curious as to what problems you had encountered that caused you to need override the Adapter. So, please email a copy of the article (if you're willing) and I'll give it a read.

BTW, I have checked a DOMTreeTableModel into incubator directory. It's not finished, but forms an interesting start of a DOM-based model.

Jeanette, I think that we should collect the various model implementations that we used a lot for testing and what not into a collected area (either the treetable subpackage, or a treatable.models subpackage). I think that having these models collected and distributed will be important for getting users to work with the tree table.

Karl

ovisvana
Offline
Joined: 2005-07-29

Hi,
I just saw your post commenting on the Actions related changes. I will try as you have said and let you know my findings. I have already mailed you a copy of my article at your kschaefe@dev.java.net email id. I will mail it again in case you have not received it.
> I am curious as to what problems you had encountered that caused you to need override the Adapter
Not many. Like I mentioned before, I didn't feel comfortable accessing the model, renderer etc from the table directly. thats all.

cheers,
prakash

kschaefe
Offline
Joined: 2006-06-08

As I go through the code, I will make some comments. This will be piecemeal, but here's the start.

I'm not convinced that you need to extend JXTreeTable.TreeTableModelAdapter. It is designed to map a TreeTableModel into a TableModel. From what I can tell, thus far (in an admittedly quick look), is that you are doing things in the SimpleTreeModelAdapter that should be done in the TreeTableModel.

Assuming that you do need to extend JXTreeTable.TreeTableModelAdapter, it is fine being a protected inner class. You should do the same. Allowing public access for this implementation detail could be very bad. That being said, if we allow the TreeTableModelAdapter to be non-final, then we should create:
[code]protected JXTreeTable(TreeTableModelAdapter adapter, TreeTableCellRenderer renderer)[/code]
constructor, which the other constructors could defer to and which subclasses that extend the TreeTableModelAdapter should use.

That's all for now.

Karl

ovisvana
Offline
Joined: 2005-07-29

>you are doing things in the SimpleTreeModelAdapter that should be done in the TreeTableModel
TreeTableModel is an interface. Do you mean 'DefaultTreeTableModel' by any chance.

>Assuming that you do need to extend JXTreeTable.TreeTableModelAdapter, it is >fine being a protected inner class. You should do the same.
Thanks. I will do that and let you know how it goes.

>we should create:
>protected JXTreeTable(TreeTableModelAdapter adapter, TreeTableCellRenderer >renderer)
Such a constructor already exists if I remember right.

BTW, my request to join the swingx project has been pending for a while now. Is anyone going to approve that or does this mean the end of the road.

cheers,
ovisvana

kschaefe
Offline
Joined: 2006-06-08

> >you are doing things in the SimpleTreeModelAdapter
> that should be done in the TreeTableModel
> TreeTableModel is an interface. Do you mean
> 'DefaultTreeTableModel' by any chance.
It is an interface. I was speaking generically about the problem. I mean your implementation of it, SimpleTreeModel. What is the Adapter doing for you that you are unable to do with the TreeTableModel (SimpleTreeModel)?

> >Assuming that you do need to extend
> JXTreeTable.TreeTableModelAdapter, it is >fine being
> a protected inner class. You should do the same.
> Thanks. I will do that and let you know how it goes.
>
> >we should create:
> >protected JXTreeTable(TreeTableModelAdapter adapter,
> TreeTableCellRenderer >renderer)
> Such a constructor already exists if I remember
> right.
Nope, it has all TreeTableModel-related constructors. The final one (which they all defer to) is
[code]private JXTreeTable(TreeTableModel, TreeTableCellRenderer)[/code]
That constructor calls super(TableModel), using the Adapter to wrap the TreeTableModel for the JXTable. I'm suggesting that that constructor defer to a protected one that accepts the Adapter, which in turn calls the super(TableModel).

Karl

kirillcool
Offline
Joined: 2004-11-17

I'm not familiar with the code, but wouldn't it be enough to make them protected so that you can extend JXTreeTable? Surely something called "treeTableHacker" shouldn't be public...

kschaefe
Offline
Joined: 2006-06-08

Does your demo currently work or are you waiting on these changes for it to work? I'd really like to take a look at this JXmlTreeTable, but last I checked I was unable to get the demo to run.

Karl

ovisvana
Offline
Joined: 2005-07-29

Hi Karl,
I'm not sure what you mean by 'does your dmo currently work?". I could get my demo to work only after downloading swingx and making the changes mentioned above. Without that, I would need to fork swingx itself which really isn't a good solution especially when something as simple as access widening would solve the problem.
Iam sorry for the demo not working. I somehow can't get wincvs to work so Iam not able to checkin the files. I can mail the files to you if you want so you can take a look at it for yourself.

Kiriil,
There's already a TreeTableHacker2 which extends TreeTableHacker and it's only natural that the JXmlTreeTable which extends JXTreeTable includes TreeTableHacker3 for extended mouse support.

also, making the method signatures 'protected' wouldn't do as then the classes and methods cannot be accessed from outside the org.jdesktop.swingx package.

cheers,
ovisvana

kschaefe
Offline
Joined: 2006-06-08

> Hi Karl,
> I'm not sure what you mean by 'does your dmo
> currently work?". I could get my demo to work only
> after downloading swingx and making the changes
> mentioned above. Without that, I would need to fork
> swingx itself which really isn't a good solution
> especially when something as simple as access
> widening would solve the problem.
> Iam sorry for the demo not working. I somehow
> can't get wincvs to work so Iam not able to checkin
> the files. I can mail the files to you if you want
> so you can take a look at it for yourself.
Yeah, I tried to look at what was checked in and didn't have any luck with it. Personally, I use Eclipse and it's integrated CVS support has worked pretty well. Yes, I'd appreciate you emailing me a copy. I'd like to see what you're doing as it may have an impact on my (slow) work with the JXTreeTable.

> There's already a TreeTableHacker2 which extends
> TreeTableHacker and it's only natural that the
> JXmlTreeTable which extends JXTreeTable includes
> TreeTableHacker3 for extended mouse support.
>
> also, making the method signatures 'protected'
> wouldn't do as then the classes and methods cannot be
> accessed from outside the org.jdesktop.swingx
> package.
Protected methods are usable by subclasses regardless of package. What I think Kiril is asking is do you really need to use any/all of this outside of a JXTreeTable subclass? For the method that do not need such wide access protected should be enough.

Karl

ovisvana
Offline
Joined: 2005-07-29

>Protected methods are usable by subclasses regardless of package.
gosh. that escaped me completely. Thanks for the reminder.

What I think Kiril is asking is do you really need to use any/all of this outside of a JXTreeTable subclass? For the method that do not need such wide access protected should be enough.
Come to think of it, Kirill is probably right. I might have subclassed and then just called the super version. I will have to check. But the editing was quite kludgy and I remember making some changes. Also, the actions weren't getting fired properly when you subclass the JXTreeTable. For example, I had added the insert, modify, delete keyboard actions to the Actions and found the derived class wasn't receiving the callbacks. Hope Iam clear what I mean. I will check about the hacker and test without any changes to see what further changes are required.

cheers,
ovisvana
.

kschaefe
Offline
Joined: 2006-06-08

> What I think Kiril is asking is do you really need to
> use any/all of this outside of a JXTreeTable
> subclass? For the method that do not need such wide
> access protected should be enough.
> Come to think of it, Kirill is probably right. I
> might have subclassed and then just called the super
> version. I will have to check. But the editing was
> quite kludgy and I remember making some changes.
> Also, the actions weren't getting fired properly when
> you subclass the JXTreeTable. For example, I had
> added the insert, modify, delete keyboard actions to
> the Actions and found the derived class wasn't
> receiving the callbacks. Hope Iam clear what I mean.
> I will check about the hacker and test without any
> changes to see what further changes are required.
If you encounter such cases, it is quite possible that there are some bugs. Obviously, if you need to hack around bugs for your article, please do so, but we should get the bugs documented, so that long term solutions can be developed.

I have received your email. I'll take a look at the JXmlTreeTable later today.

Karl

ovisvana
Offline
Joined: 2005-07-29

I was right. Protected access isn't enough. Iam getting the following errors:

SimpleTreeModelAdapter.java:86: org.jdesktop.swingx.JXTreeTable.TreeTableModelAdapter has protected access in org.jdesktop.swingx.JXTreeTable
public class SimpleTreeModelAdapter extends JXTreeTable.TreeTableModelAdapter implements MouseListener {
^
JXmlTreeTable.java:39: org.jdesktop.swingx.JXTreeTable.TreeTableDataAdapter has protected access in org.jdesktop.swingx.JXTreeTable
import org.jdesktop.swingx.JXTreeTable.TreeTableDataAdapter;
^
JXmlTreeTable.java:373: org.jdesktop.swingx.JXTreeTable.TreeTableCellRenderer is
not public in org.jdesktop.swingx.JXTreeTable; cannot be accessed from outside
package
protected class XmlTreeTableCellRenderer extends JXTreeTable.TreeTableCellRenderer {
^
JXmlTreeTable.java:181: org.jdesktop.swingx.JXTreeTable.TreeTableCellRenderer is
not public in org.jdesktop.swingx.JXTreeTable; cannot be accessed from outside
package
public void init(TreeTableCellRenderer renderer) {
^
JXmlTreeTable.java:206: org.jdesktop.swingx.JXTreeTable.Actions has private acce
ss in org.jdesktop.swingx.JXTreeTable
private class GridActions extends JXTreeTable.Actions {
^
JXmlTreeTable.java:145: cannot find symbol
symbol : method initActionsAndBindings()
location: class demo.JXmlTreeTable
initActionsAndBindings();
^
JXmlTreeTable.java:198: initActions() has private access in org.jdesktop.swingx.
JXTreeTable
super.initActions();
^
JXmlTreeTable.java:494: treeTableHacker has private access in org.jdesktop.swing
x.JXTreeTable
if (treeTableHacker == null) {
^
...

The rest of the errors are related to the above and should disappear once the above are fixed.

cheers,
ovisvana

kschaefe
Offline
Joined: 2006-06-08

> I was right. Protected access isn't enough. Iam
> getting the following errors:
Sure, if you place the Adapter, etc. outside of the JXTreeTable subclass. I believe the intention was that such subclasses (of Adapter, etc.) should be inner classes, as the original ones were.

ovisvana
Offline
Joined: 2005-07-29

Hi,
But the adapter class if not the renderer has grown in size since I started adding functionality to it that I think they deserve to be first class classes by themselves. Adding them as inner classes would make the treetable class unwieldy. Correct me if Iam wrong.

cheers,
prakash