Thread: ListDataListener get removed element

That's a rough one... I'm not sure if there is a native way of doing it. However, if you can find in the source code where the fire method for the event handling, and if we can override that method, we might be able to "hack" it include the object in the event's payload.

--- Update ---

Ok, I have a hack for it, but it requires a bit of overriding.
First, create a new class which extends ListDataEvent and just has additional payload:

public class MyListDataEvent extends ListDataEvent {
	private Object removedObject;
 
	public ListDataEvent(Object source, int type, int index0, int index1, Object removed) {
		super(source,type,index0,index1);
		removedObject = removed;
	}
 
	public Object getRemovedObject() {
		return removedObject;
	}
}

Now we want to create a new fire method and override the remove method in our DefaultListModel. So if you are using the DefaultListModel (instead of extending it with another class), you would do:

new DefaultListModel() {
	protected void fireIntervalRemoved(Object source, int startIndex, int endIndex, Object removed) {
		ListDataEvent event = new MyListDataEvent(source,ListDataEvent.INTERVAL_REMOVED,startIndex,endIndex,removed);
		ListDataListener[] listeners = getListDataListeners();
		for (int index = 0; index < listeners.length; index++)
			listeners[index].intervalRemoved(event);
	}
	@Override
	public Object remove(int index) {
		Object rv = delegate.elementAt(index);
		delegate.removeElementAt(index);
		fireIntervalRemoved(this,index,index,rv);
		return rv;
	}
	@Override
	public void removeElementAt(int index) {
		remove(index);
	}
	@Override
	public boolean removeElement(Object obj) {
		int index = indexOf(obj);
		boolean rv = delegate.removeElement(obj);
		if(index>=0 && rv)
			fireIntervalRemoved(this,index,index,obj);
		return rv;
	}
};

We overrode the remove methods to use our new fireIntervalRemoved() method, which uses our new event.
So your intervalRemoved() method would change to:

public void intervalRemoved(ListDataEvent e) {
	if(e instanceof MyListDataEvent) {
		Object thatWasRemoved = ((MyListDataEvent)e).getRemovedObject();
		System.out.println("Removed: "+thatWasRemoved);
	}
}

That *should* "hack" it with the behavior, but I haven't tested it. Tell me if you come across any issues.

I'm not aware of any alternative solution, but I'm not some omniscient java god or anything, so there could be other ways, lol.
The problem is that you need additional payload information, and the ListDataEvent doesn't provide any fields for additional payload. By the time the normal event is fired, the object has already been removed from the model's delegate vector. So unless you create some exact parallel vector, you've lost the object (I would not advise this, since trying to keep the two in parallel would be an incredible pain in the ass).
As for changing the ListDataModel and other people modifying it in the future, the best suggestion I have for that is: make the dependency heavily documented.

Why do you need the removed elements? Can you deal with the removed elements in the portion of code that removes them rather than using a Listener?

Complicated indeed...but I still don't understand why you need to know which attributes were removed. I ask this question in the off chance there may be a better way to design the app based upon the answer.

I don't know what you mean by 'cloned attribute', but presuming it is a member of the same 'interface' as the attribute it is 'cloned' from, then a tree data structure sounds like something to consider. A 'class' is a grandparent, 'interface' a parent, 'attribute' a child, and 'cloned' attribute a grandchild (or some subset thereof). Anytime an attribute is removed, so are its cloned. Again, I'm not fully sure I follow the entire outline, but consider taking a step back and looking at the organization of your model - typically if I end up in a position such as this (in which a project relies on well built API which suddenly doesn't do it for me), I find it often best to step back and think hard about how the model is organized - often resulting in a different (and better (although better is often relative)) design.

I believe I understand the original problem - the suggestion for using a Tree was not to directly address that problem. Rather, it was an indirect suggestion about how the 'model' of your program is designed. Whether or not a Tree is appropriate is up to you...the idea was to rethink your overall design. As the problem is stated - it sounds like your model is quite tightly integrated with you user interface - a reliance which causes issues like this, whose fixes can be rudimentary hacks which could introduce bugs and make later changes that much more difficult. A full redesign might sound like a lot of work, but is always worth considering.

How I often design data models (rightly or wrongly) is by ignoring any UI altogether. Design the concrete classes of the model and any data structures which organize/manage these classes. One can also implement edit methods within the model which fire its own listener system. There are many reasons to recommend doing so - it makes the model readily customizable, easy to make changes without breaking things, independent of constraints like you ran into above, helps allow you to use the framework in another project, and helps make the code independent of the UI - allowing you to swap (or use multiple) UI if necessary (Swing, command line, JavaFX, J2EE, or J2ME).

My 0.02. Sorry if this doesn't directly address your problem.

Originally Posted by Cornix

I guess I understand what you mean.
You say I should not use the ListModel from the Swing framework and rather use my own Listener classes for inter-object communication within the data model. Then, when integrating the Data into a swing GUI I would wrap a ListModel around my initial design to make it compatible with Swing UI components.
Is that correct?

Pretty much.

Originally Posted by Cornix

At first I tried it that way, but then realized that I was doing everything twice. It was almost like copied code that did the same thing but for different interfaces.
I thought that by merging both together I could make the design more stable and readable instead of having everything doubled.

I'd prefer to use the word 'delegate' - the Swing models are used as delegates to access the underlying data model. You may need to implement a few more methods for the delegate, so in this sense it seems like more code is required, and it may seem this code is duplicated. For small programs this may not be necessary, but as programs grow and the data model gets more complex it can be a lot more flexible. Your mileage may vary