Hi,
aside from all the discussion of whether listener lists are serialized or
not, I have a question. Are you really interested in the TableModel's
private data (ie. the state of listeners attached to the model?). Usually
when I write any TableModel, it's based on some real data. This data has
absolutely nothing to do with a Table usually, or at best it just so happens
that it is easy for a user to read it in tabular form. Usually when you
create a TableModel you are interested in representing data in a tabular
form some client. Usually, I don't need to remember who those client's were.
I can recreate those client registrations in some other way. What I
crucially need is the data that I wanted to format.
My advice is never code your domain objects to be TableModels. Your domain
objects should be just that and nothing more.( (Collections of simple data
objects usually).
I then can then write several GoF adapters that take my domain object lists
in their constructors. The adapters job is to make my domain object lists
"swing-friendly" by adapting them to swing interfaces. So you may have a
TableModelAdapter, a ComboBoxModelAdapter, or a ListModelAdapter etc, all of
which use the same underlying domain object. This means you don't polute any
of your domain objects with swing-interface leanings, and they are much more
reusable.
Then this whole serialisation question becomes how can I serialise my domain
objects? You know about them better than anyone else, you can create your
adapters from them, and register listeners with the adapters.
Sorry if this rant put you to sleep...
Neil
-----Original Message-----
From: Paul Brinkley [mailto:[EMAIL PROTECTED]]
Sent: 05 March 2001 16:28
To: [EMAIL PROTECTED]
Subject: Re: AbstractTableModel serialization problem
At 04:41 PM 3/5/2001 +0100, Kleopatra wrote:
>"Wathen, Dave" schrieb:
> >
> > I agree with Paul this shouldn't be happening. Do you have a
> > reference to the table in your subclass of AbstractTableModel
> > (either directly or indirectly). The listeners are transient
> > references.
> >
>
>Why do you think they are transient?
>
>Here is the listenerlist declaration of AbstractTableModel
>
> /** List of listeners */
> protected EventListenerList listenerList = new EventListenerList();
>
>And here is the actual storage in EventListenerList
>
> protected transient Object[] listenerList = NULL_ARRAY;
>
>true, it's transient, but only to be able to write all the listeners
>manually to the objectoutpstream in case some of them are not
>serializable:
>
>[code snipped]
>
>In total: every listener is serialized to the outputstream....
Every -serializable- listener, that is.
Your post did tell me something I wasn't aware of, but should have
realized: while EventListeners aren't serializable, Java will attempt to
save an EventListener object if it implements java.io.Serializable in
some other way. JTable is such a case.
By the way, here's a link to an explanation as to why EventListeners
are not serializable by default. I've found it useful for back reference
on multiple occasions.
http://developer.java.sun.com/developer/bugParade/bugs/4031001.html
WRT to the original problem, I'm leaning more and more toward
recommending a special method for saving only the data in an
AbstractTableModel subclass, unless there's no chance that the
subclass will ever be re-used.
I haven't had much experience yet with beans, but your solution
looks okay, so long as nothing assumes that any instance of
ATM is following the usual scheme for listeners. (That is, no
outside code assumes it can check whether a particular JTable is
listening to a particular ATM, for example.) I'd say that 95% of the
time, this will not be a problem, but again, I haven't wrangled around
event listeners enough to know for sure.
>To solve the original problem, I implemented the actual
>adding/removing/notification of TableModelEvents inside a class
>TableModelSupport (in analogy to PropertyChangeSupport in java.beans)
>and let my custom table model have a transient variable to that support.
>Now it's possible to use fine grained control about which listeners are
>written and which are not. Don't forget to initialze the support on
>readObject(). If the custom derives from some AbstractTableModel (I
>often customize DefaultTableModel) then make sure to overwrite
>add/removeTableModelListener/fireTableChanged(TableModelEvent e) to
>delegate to TableModelSupport.
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
**********************************************************************
This email is intended only for the addressee. This email
and any files transmitted with it may contain confidential
or privileged information. If you are not the named
addressee or the person responsible for delivering the
message to the named addressee, please contact
[EMAIL PROTECTED]
This email has been scanned by MAILsweeper.
**********************************************************************
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
