Re: [Jsynthlib-devel] XML patch saving....

[Joe E. <jo...@em...>]

Rib Rdb wrote:
> On 3/8/06, Joe Emenaker <jo...@em...> wrote:
>   
>> True. Which is why I said "If any of those getters return anything other
>> than String (or any other data types we know how to save and restore),
>> then throw an exception, or fail, or complain, or do something". In
>> other words, if the author added a getter like "Hashtable
>> getHashtableofsomething()", then the XML saving code would throw up a
>> warning message saying "Hey! We don't know how to save
>> 'java.util.Hashtable', so you're going to lose the data returned by
>> 'getHashtableofsomething()'!".
>>     
>
> I still think this has problems.  How do you handle transient data or
> data which has multiple getters and setters?
Well, I think I hinted, at one point, at the idea of, instead of trying 
to autodetect the public getters and setters, maintaining an array or 
vector of the property names to save. For example, if the vector 
contained "Name", "Author", and "Date", then the XML load and save code 
would only try to call getName, setName, getAuthor, setAuthor, etc. But, 
if my suggestions thus far have made you uncomfortable, then *this* idea 
has probably got you squirming. :)
> Name has getters and
> setters, but may also be stored inside sysex.
Well, that's a device-specific trait, and it affects the current 
serialization method just as much as it would any new XML method. In 
other words, as JSL stands now, the "name" string is stored along with 
the sysex data and it's loaded with it, too. If individual driver 
classes choose to override getName and setName to access the sysex data 
directly and not use the "name" string, it shouldn't matter.
> Sysex data can be
> accessed as bytes or sysex messages, and now strings.  How do we
> decide when to throw exceptions for unstorable data and which data
> isn't supposed to be stored?
>   
Well, if we didn't have a vector of properties to save, then we'd have 
to use matching pairs of public getters/setters.
>> Now, I just thought of another way, which would use your "write()"
>> methods without requiring super.write(). Using inspection, I think it
>> *is* possible to make calls to the over-ridden methods of a superclass.
>> In other words, the XML writing code could call a class' write(), and
>> then call its superclass' write(), and then *that* superclass'
>> superclass' write(), etc.... until it got all the way to the original
>> class. But that's a little spooky.
>>     
> Yeah.  And then you have problems if someone does call super.write().
>   
Well, I knew that when I suggested it.... but it's not that big of a 
problem because you'd just get two copies of some data items and, at 
worst, it would just result in duplicate calls to setName, setWhatever.....

You're starting to convince me that the super.write() method is the path 
of least resistance... but I *have* tried this very solution before and 
it looked great on paper and turned into a bit of a pain when it was put 
into practice. So, forgive me if I'm a little gun-shy about it.

- Joe