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

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

Rib Rdb wrote:
> On 3/9/06, Joe Emenaker <jo...@em...> wrote:
>   
>> The default constructor is supposed to be called for all subclasses that
>> don't explicitly specify a super constructor in their own constructor.
>> So, if I subclass Patch in a class called SpecialPatch and write:
>>    public SpecialPatch() {
>>      addPropertyName("SomeSpecialData");
>>    }
>>
>> then the Author and Comment ones should still get put into the vector.
>>     
>
> Do you really think anyone is ever going to subclass Patch.
I don't understand why Scene didn't, actually.
> Have you seen how much of it is final?
Well, that part's easy. You just delete the "final" part. :)
> The main reason IPatch was created was
> so people don't have to subclass Patch.
"so people don't have to" make use of the existing code in Patch and, 
instead, have to write every method anew? Well, we shouldn't dwell on 
"how come it wasn't done *this* way?" stuff.
> I certainly like the idea of having a read method. But the parser I
> wrote is event based (SAX), so a read method doesn't easily translate.
> But I suppose we could make it work.
>   
Well, it doesn't appear to me that our data format is going to require 
SAX and the "order-ness" that it provides. I mean, if the <Author> 
element comes before or after the <Sysex> element... what does it 
matter, as long as they all appear within the same <Patch> element? 
Furthermore, does SAX even have an easy system for writing the XML to a 
file? With DOM, you can read an XML into a Document and then save it 
write back out with a couple of lines of code.
>> Lastly, the readProperty() method(s) should be really easy to write, since we can have the "xml." part of "xml.readProperty" holding the DOM Node for just that patch... and readProperty could just turn right around return the value returned by "getAttribute()" for that node.
>>     
> Do you mean to store all the data as attributes of an element instead
> of children?
Not necessarily. In fact, I was going to touch on that issue next. 
Although all of the data that's currently saved (except for sysex) is 
short enough for use as attributes, we wouldn't have control over 
subclasses (and/or future implementations of IPatch). So, we could 
either give the author a choice (like xml.writeElement() and 
xml.writeAttribute()) or just force everything to be an Element.

I'm leaning toward just making everything an Element. Partly because you 
see to really want that and also because my next suggestion is that we 
make this whole thing not XML-specific. In other words, instead of a

  void write(XMLWriter xml)

method, it could be

  void write(PropertyHolder props)

and PropertyHolder (or... "PropertyBasket" if we want to use exiting JSL 
nomenclature :) ) would just hold all of the values that the patch 
object wanted to be saved. So, when a user clicks "Save" in JSL, JSL 
would...

 1 - Create an empty DOM
 2 - Get the next patch in the PatchBasket
 3 - Create an empty "patch" DOM Element
 4 - Create an empty PropertyHolder
 5 - Call the patch's write(PropertyHolder) method with the new, empty 
one we just made
 6 - Write those properties to the patch DOM Element
 7 - Back to step 2

The things to note here are that the patch classes would have no idea 
that we were using XML at all. Only the methods doing the actual 
save/load would know. This would allow us to change the format, or to 
support various formats. Even if we never decided to change the *file* 
format again, we could still use the PropertyHolder idea to support 
other formats for other purposes.... like transmission over the net or 
copy/paste or something like that.

- Joe