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

[Rib R. <ri...@gm...>]

On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > On 3/9/06, Joe Emenaker <jo...@em...> wrote:
> >
> >> The default constructor is supposed to be called for all subclasses th=
at
> >> 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.

I don't know why it didn't originally, but if it used a subclass of
Patch then you couldn't have a scene containing XMLPatches

> > Have you seen how much of it is final?
> Well, that part's easy. You just delete the "final" part. :)

I would assume we put those there for a reason.

> > 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.

"so people don't have to" be restricted by the design of the Patch class.

> > 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.

I'm not saying we need sax.  I'm just trying to explain why I
suggested using setters instead of a single read method -- There's
already a parser in CVS that works that way.

> >> Lastly, the readProperty() method(s) should be really easy to write, s=
ince we can have the "xml." part of "xml.readProperty" holding the DOM Node=
 for just that patch... and readProperty could just turn right around retur=
n 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.

I guess I just prefer the extreme programming approach.  Why make it
more complicated now to support something that we might possibly want
to use at some point in the future.  I'd rather keep the design simple
now, and then when it needs to change, find the best design for the
new requirements.  But whatever.  I don't have time to write a new
parser and XML writer.  If you do, go right ahead.