nodeChanged() method for DefaultTreeTableModel?

[jdnc-interest]

If I have a DefaultTreeTableModel how can I fire event saying that a node has been changed?  I don't see the equivalent to a DefaultTreeModel nodeChanged() method.  Any help is appreciated.  Thanks.
[Message sent by forum member 'chaddaniels' (chaddaniels)]

http://forums.java.net/jive/thread.jspa?messageID=288221

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

[jdnc-interest]

There isn't such a method.  If you use the node alteration methods (removeFromParent, etc) there automatically perform notifications.

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=288232

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

[jdnc-interest]

It makes sense that calling removeFromParent on a child would cause a nodeRemoved event to fire, but how about if I am not adding/removing nodes, but rather a nodes internal representation has been modified and should be reflected in the tree?
[Message sent by forum member 'chaddaniels' (chaddaniels)]

http://forums.java.net/jive/thread.jspa?messageID=288239

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

[jdnc-interest]

The setValueAt already notifies as well.  You should not need to perform any manual notifications when using the DefaultTreeTableModel.

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=288247

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

[Kleopatra]

Karl,
> The setValueAt already notifies as well.  You should not need to perform any manual notifications when using the DefaultTreeTableModel.
>
>  

we had been through this before, hadn't we :-)

In fact there is a need to do _something_ (be it manual notification or
subclassing the model) - several use cases are uncovered

- the equivalent to a setUserObject on the underlying node. While often
it can be exposed in one of the columns, that's not necessarily the case.

- inserting/removing multiple nodes

- notifying about structure change below a node (not every structure
change can be expressed in terms of insert/remove)

CU
Jeanette



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

[jdnc-interest]

Jeanette,

> we had been through this before, hadn't we :-)
Yes, and without a runnable, usable test case, I remain patently unconvinced that external notifications are required.  You could simply be interpreting a new user's question into something that it is not.

> In fact there is a need to do _something_ (be it
> manual notification or
> subclassing the model) - several use cases are
> uncovered
And I would argue that the model needs additional methods to aid in this.  Opening notification is not one of them.  Show me a use-case where improving model methods does not solve the problem and I will agree with you.

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=288418

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

[Kleopatra]

Karl,

>> In fact there is a need to do _something_ (be it
>> manual notification or
>> subclassing the model) - several use cases are
>> uncovered
>>    
> And I would argue that the model needs additional methods to aid in this.  

which would fall under the second option suggested above - only that the
need for subclassing might have been resolved trivially <g> As un-pure
as it is (and violating the RULES), I _always_ subclass to add the
notification methods (or open up the treeModelSupport) -  it often feels
so much easier than to think of more general solution to pass-through
the model.

> Opening notification is not one of them.  Show me a use-case where improving model methods does not solve the problem and I will agree with you.
>
>
>  

show me the improved model methods - then I can tell if they suite my
needs or not ;-) Kidding a bit, but actually I'm not entirely sure that
it's possible in all contexts. And I suspect that the latent
impossibility to  really cover all needs might be the pragmatic reason
they were added to the DefaultTreeModel in the first place.

Cheers
Jeanette








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

[jdnc-interest]

Jeanette,

> > And I would argue that the model needs additional
> methods to aid in this.  
>
> which would fall under the second option suggested
> above - only that the
> need for subclassing might have been resolved
> trivially <g> As un-pure
> as it is (and violating the RULES), I _always_
> subclass to add the
> notification methods (or open up the
> treeModelSupport) -  it often feels
> so much easier than to think of more general solution
> to pass-through
> the model.

Remember that the DefaultTreeTableModel is designed to work (and only to work) with TreeTableNodes.  I think the all of the rules are definable in this limited context.  If it is necessary for the user to create a model that works outside of this context that user can extend AbstractTreeTableModel and open up the notification as they see fit.

> > Opening notification is not one of them.  Show me a
> use-case where improving model methods does not solve
> the problem and I will agree with you.
>
> show me the improved model methods - then I can tell
> if they suite my
> needs or not ;-) Kidding a bit, but actually I'm not
> entirely sure that
> it's possible in all contexts. And I suspect that the
> latent
> impossibility to  really cover all needs might be the
> pragmatic reason
> they were added to the DefaultTreeModel in the first
> place.

Again, DefaultTreeTableModel is not all contexts; it the TreeTableNode context.  I'm not arguing that opening notification is not valid (I'll save that fight for another day ;), I'm arguing that for DefaultTreeTableNode that it is not valid.  The context that that model handles is limited to the degree that we can conceivably handle the cases without opening the notification.

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=288476

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

[Kleopatra]

Karl,

>
> Remember that the DefaultTreeTableModel is designed to work (and only to work) with TreeTableNodes.  I think the all of the rules are definable in this limited context.  If it is necessary for the user to create a model that works outside of this context that user can extend AbstractTreeTableModel and open up the notification as they see fit.
>
>  

Hmm .. even then, I don't think that all mutations and modification  are
completely definable through the model. Let's see what we have and what
we need

we have:
- support for single node insert/remove.
- support for setting columnar values

we do not have
- support for multiple insert/remove: client code is forced to break
down to single insert/remove. Could be argued to be a nuisance only (not
by me <g>)
- support for setUserObject
- assuming we add a setUserObject, that's not necessarily enough as
there might be implementations of TreetableNode which do not support the
setting (f.i. if they regard themselves as the userObject) but have
mutable propeties which are not exposed via any setValueAt. In this
case, the client code which mutates the properties must have some means
to force the model to fire a notification.
- access to structureChanged might be needed as well: an example might
be sorting where some property changes lead to sequence changes which
are too complex (or too much bother) to break down into individual
insert/remove.

So my take in this would be to go the same way the core team did (they
most probably had their reasons) But open for suggestions to do the
above without opening the notification, always eager to learn a new
trick :-)

Anyway, recently cleaned my wrapper implementation of a TreeTableModel
which allows the use any TreeModel and adapt it to a TreeTableModel via
a NodeModel (the wrapper is called TreeTableModelAdapter and moved into
the treetable package under the kleopatra/java source tree). With that,
developers can re-use any custom tree model, f.i. their beloved
DefaultTreeModel with its open notification :-) Will open a new thread
for a review, so if considered useful we could add it to swingx as soon
as ... when?

CU
Jeanette



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

[jdnc-interest]

[duplicate - gateway down ... ]

Karl,

>
> Remember that the DefaultTreeTableModel is designed to work (and only to work) with TreeTableNodes.  I think the all of the rules are definable in this limited context.  If it is necessary for the user to create a model that works outside of this context that user can extend AbstractTreeTableModel and open up the notification as they see fit.
>
>  

Hmm .. even then, I don't think that all mutations and modification  are completely definable through the model. Let's see what we have and what we need

we have:
- support for single node insert/remove.
- support for setting columnar values

we do not have
- support for multiple insert/remove: client code is forced to break down to single insert/remove. Could be argued to be a nuisance only (not by me <g>)
- support for setUserObject
- assuming we add a setUserObject, that's not necessarily enough as there might be implementations of TreetableNode which do not support the setting (f.i. if they regard themselves as the userObject) but have mutable propeties which are not exposed via any setValueAt. In this case, the client code which mutates the properties must have some means to force the model to fire a notification.
- access to structureChanged might be needed as well: an example might be sorting where some property changes lead to sequence changes which are too complex (or too much bother) to break down into individual insert/remove.

So my take in this would be to go the same way the core team did (they most probably had their reasons) But open for suggestions to do the above without opening the notification, always eager to learn a new trick :-)

Anyway, recently cleaned my wrapper implementation of a TreeTableModel which allows the use any TreeModel and adapt it to a TreeTableModel via a NodeModel (the wrapper is called TreeTableModelAdapter and moved into the treetable package under the kleopatra/java source tree). With that, developers can re-use any custom tree model, f.i. their beloved DefaultTreeModel with its open notification :-) Will open a new thread for a review, so if considered useful we could add it to swingx as soon as ... when?

CU
Jeanette



---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@...
For additional commands, e-mail: jdnc-help@...
[Message sent by forum member 'kleopatra' (kleopatra)]

http://forums.java.net/jive/thread.jspa?messageID=289807

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

[jdnc-interest]

Jeanette,

Quickly examining your comments:
> we do not have
> - support for multiple insert/remove: client code is
> forced to break down to single insert/remove. Could
> be argued to be a nuisance only (not by me <g>)
This is partially hampered by the fact that TreeModelEvent does not allow multi-depth notifications.  So all we can really add are multi-notification at the same level.  Yeah, I would'nt argue for it, but when do I ever do that. ;)

> - support for setUserObject
This is changing the data that is backing the model.  No model supports changes that it doesn't know about.  Change the backing list for a TableModel; there is no expectation that the model with do the right thing.  The counterpoint is that AbstractTableModel, for instance, would allow me to notify.  But, I think such notification breaks the containment that the model claims to provide.

> - assuming we add a setUserObject, that's not
> necessarily enough as there might be implementations
> of TreetableNode which do not support the setting
> (f.i. if they regard themselves as the userObject)
> but have mutable propeties which are not exposed via
> any setValueAt. In this case, the client code which
> mutates the properties must have some means to force
> the model to fire a notification.
This is potentially the closest argument so far.  But again why are we changing properties outside of the model?  So far, your arguments are we can change X and the model doesn't know.  My argument is that the model should always know and that it's bad, bad, bad to perform changes without the model being aware.

> - access to structureChanged might be needed as well:
> an example might be sorting where some property
> changes lead to sequence changes which are too
> complex (or too much bother) to break down into
> individual insert/remove.
Sorting and filtering are the perview of the view.  The view should repaint the data.  The view should recieve notifications of sorting/filtering outside of this context.

> So my take in this would be to go the same way the
> core team did (they most probably had their reasons)
> But open for suggestions to do the above without
> opening the notification, always eager to learn a new
> trick :-)
Not so much of a trick as a way of working with the world.  I never modify my data outside of a model, unless I'm done with the model or am going to reset the model with the new data.

> Will
> open a new thread for a review, so if considered
> useful we could add it to swingx as soon as ...
> when?
You're the one who keeps refusing to add more classes in scope for 1.0.  You tell me when it should go in.  :)

Karl
[Message sent by forum member 'kschaefe' (kschaefe)]

http://forums.java.net/jive/thread.jspa?messageID=289824

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

[Kleopatra]

Karl,

quick answer before calling it a day ..
>
> This is partially hampered by the fact that TreeModelEvent does not allow multi-depth notifications.  So all we can really add are multi-notification at the same level.  Yeah, I would'nt argue for it, but when do I ever do that. ;)
>
>  

yeah, sure - multi-level events aren't supported. But funnily, recently
I had to do multiple one-level events quite often - though mostly in
testing ;-) Arguably my point is a bit on the convenience side: the
treeModelEvent supports multiple inserts/removes, so expect client code
to have a need for it, so the default implementation should support it
as well.

>> - support for setUserObject
>>    
> This is changing the data that is backing the model.  

no - that's a valid mutator method on the TreeTableNode. Same  as in
core MutableTreeNode. If we can't use it through the model and have no
way to trigger a nodeChanged, the method is simply useless. That's what
you want, coming to understand your intentions ... <g>
> No model supports changes that it doesn't know about.  
sure, DefaultTreeModel does by exposing the external notification
methods, which I think is not a design accident as in some of the others.

> This is potentially the closest argument so far.  But again why are we changing properties outside of the model?  So far, your arguments are we can change X and the model doesn't know.  My argument is that the model should always know and that it's bad, bad, bad to perform changes without the model being aware.
>
>  

well, then the model must add listeners to each node. Which would be
very pure and clean - but rarely seen out in the wild ;-) What actually
happens is that client code subclasses the DefaultTreeTableModel and
c&p's the code from DefaultTreeModel.

Cheers
Jeanette

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

[jdnc-interest]

[duplicate - forgot that the gateway from the mailinglist is broken}

Karl,

quick answer before calling it a day ..
>
> This is partially hampered by the fact that TreeModelEvent does not allow multi-depth notifications.  So all we can really add are multi-notification at the same level.  Yeah, I would'nt argue for it, but when do I ever do that. ;)
>
>  

yeah, sure - multi-level events aren't supported. But funnily, recently I had to do multiple one-level events quite often - though mostly in testing ;-) Arguably my point is a bit on the convenience side: the treeModelEvent supports multiple inserts/removes, so expect client code to have a need for it, so the default implementation should support it as well.

>> - support for setUserObject
>>    
> This is changing the data that is backing the model.  

no - that's a valid mutator method on the TreeTableNode. Same  as in core MutableTreeNode. If we can't use it through the model and have no way to trigger a nodeChanged, the method is simply useless. That's what you want, coming to understand your intentions ... <g>
> No model supports changes that it doesn't know about.  
sure, DefaultTreeModel does by exposing the external notification methods, which I think is not a design accident as in some of the others.

> This is potentially the closest argument so far.  But again why are we changing properties outside of the model?  So far, your arguments are we can change X and the model doesn't know.  My argument is that the model should always know and that it's bad, bad, bad to perform changes without the model being aware.
>
>  

well, then the model must add listeners to each node. Which would be very pure and clean - but rarely seen out in the wild ;-) What actually happens is that client code subclasses the DefaultTreeTableModel and c&p's the code from DefaultTreeModel.

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@...
For additional commands, e-mail: jdnc-help@...
[Message sent by forum member 'kleopatra' (kleopatra)]

http://forums.java.net/jive/thread.jspa?messageID=289836

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

[Kleopatra]

Kleopatra schrieb:

been a long time ... but
>>> - support for setUserObject
>>>    
>> This is changing the data that is backing the model.  
>
> no - that's a valid mutator method on the TreeTableNode. Same  as in
> core MutableTreeNode. If we can't use it through the model and have no
> way to trigger a nodeChanged, the method is simply useless. That's
> what you want, coming to understand your intentions ... <g>

just filed an issue (and assigned to you, Karl :-)

Cheers
Jeanette

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

[Kleopatra]

Kleopatra schrieb:
>
> just filed an issue (and assigned to you, Karl :-)
>

forgot the reference:

https://swingx.dev.java.net/issues/show_bug.cgi?id=915

CU
Jeanette

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