|
Replies:
5
-
Last Post:
Jul 25, 2007 5:16 AM
by: kschaefe
|
|
|
|
|
|
|
AbstractTreeModel, do we need one?
Posted:
Jul 24, 2007 9:46 AM
|
|
|
I've always felt that the AbstractTreeModel was an important, yet missing feature in the JTree. After reading a thread, where someone is having trouble with the current model, it got me to thinking: should SwingX provide an AbstractTreeModel?
Karl
|
|
|
|
|
|
|
Re: AbstractTreeModel, do we need one?
Posted:
Jul 24, 2007 10:25 PM
in response to: kschaefe
|
|
|
> it got me t thinking: should SwingX provide an AbstractTreeModel?
>
> Karl
You already know the answer ... it could.
Since you've done all the research already, go ahead, create one, put it in the incubator, we can test and review it as it develops and when api is deemed stable enough you can move it to the main base to make it more visible to the rest of world to see how useful it is to everybody.
Jan
|
|
|
|
|
|
|
|
|
Re: AbstractTreeModel, do we need one?
Posted:
Jul 24, 2007 11:41 PM
in response to: rah003
|
|
|
good early morning stuff - controversals always wake me up, (nearly)
better than the espresso beside me <g>
>> it got me t thinking: should SwingX provide an AbstractTreeModel?
>>
>> Karl
>
> You already know the answer ... it could.
my answer is a no.
- the Abstract* layer in the other models is an abomination, forcing
developers into inheritance instead of delegation. This leads to code
duplication (smelllly) if they can't extend, f.i. if a model needs to
serve more than one xxModel interface.
- SwingX has the TreeModelSupport which does the notification. There's
not much more a Abstract* layer can do in the general case.
That said, in my early days in the project there had been an interesting
discussion between Patrick and Ramesh about how to support easier
treeModel handling. Didn't follow it at that time, and don't have the
link, but searching the forum might turn it up. And there should be some
code in the incubator (under the old tree src/java/ tree)
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: AbstractTreeModel, do we need one?
Posted:
Jul 25, 2007 2:06 AM
in response to: Kleopatra
|
|
|
I would not put it down so quickly, tree structures are more difficult for people to deal with then most of other data structures. Therefore anything that puts its processing in smaller layers that are easier to understand is potentially helpful. Also there are many different purposes people use trees for so we can have one abstract model and then more specialized non abstract ones suited best for different purposes.
Besides there is already a precedent set by AbstractTreeTableModel ... if you feel so strongly about that being abomination, perhaps we should have an issue to factor it out elsewhere and deprecate or remove it.
In any case I would like see it first before making any kind of judgment.
|
|
|
|
|
|
|
|
|
Re: AbstractTreeModel, do we need one?
Posted:
Jul 25, 2007 4:17 AM
in response to: rah003
|
|
|
> Besides there is already a precedent set by AbstractTreeTableModel ... if you feel so strongly about that being abomination, perhaps we should have an issue to factor it out elsewhere and deprecate or remove it.
I gave in  For exactly the reason ...
>
> In any case I would like see it first
... and still think it's doing not enough (or merely so) to varant its
existence. Won't vote against it, though - if there's a majority to go
for it, we'll go.
I'm all in for making complex things easier. But look at the
AbstractTreeTableModel and take out the treeTable related methods ..
In my experience the hard thing about tree/model is event notification.
And the hard thing about event notification is to fire the correct
events. A method like (from DefaultTreeModel):
/**
* Notifies all listeners that have registered interest for
* notification on this event type. The event instance
* is lazily created using the parameters passed into
* the fire method.
*
* @param source the node being changed
* @param path the path to the root node
* @param childIndices the indices of the changed elements
* @param children the changed elements
* @see EventListenerList
*/
protected void fireTreeNodesChanged(Object source,
Object[] path, int[] childIndices,
Object[] children) {
is simply ... not understandable (it wasn't for me ... who would
guess that the "path" parameter is the path from the parent to the root?
What's needed is to formulate the fireXX in more in terms of
"tree-speak", that's what the TreeModelSupport tries to do. So I would
put the effort there to improve the support and then start thinking of
what the AbstractModel might add in easing the burden.
Another puzzle is the valueForPathChanged ... it's rarely guessed that
this is where the tree hooks in after an edit and that the method has to
update the end-of-the-path with whatever interpretation of newValue
makes sense in the context and to fireTreeNodesChanged... on the
parentPath <g>
Okay, back to DatePicker
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: AbstractTreeModel, do we need one?
Posted:
Jul 25, 2007 5:16 AM
in response to: Kleopatra
|
|
|
> > You already know the answer ... it could.
>
> my answer is a no.
Jan, I asked specifically because I expected Jeanette to say no. 
> - the Abstract* layer in the other models is an
> abomination, forcing
> developers into inheritance instead of delegation.
> This leads to code
> duplication (smelllly) if they can't extend, f.i. if
> a model needs to
> serve more than one xxModel interface.
Possibly, but the default models tends to...be not so good. The AbstractXXXModels should be designed for extensions, which they are for the most part. The XXXSupport approach is worthwhile, but there tends to be methods outside of them that are boilerplate. Personally, I like the interface, abstraction, and implementation approach because it
1) works on all levels. There are easy pieces to use with the default implementations, good starting points for developers with the abstraction, and a completely open space with the interface.
2) is very educational. I tend to discover more about code by looking at good source files. Seeing how event notification works in a default implementation that is supported by an abstract one gives me the knowledge to do the right thing for a custom model that I build that extends the abstract model.
> - SwingX has the TreeModelSupport which does the
> notification. There's
> not much more a Abstract* layer can do in the general
> case.
>
> That said, in my early days in the project there had
> been an interesting
> discussion between Patrick and Ramesh about how to
> support easier
> treeModel handling. Didn't follow it at that time,
> and don't have the
> link, but searching the forum might turn it up. And
> there should be some
> code in the incubator (under the old tree src/java/
> tree)
I will look into it.
Karl
|
|
|
|
|
java.net RSS
