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

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

On 3/7/06, Joe Emenaker <jo...@em...> wrote:
> Rib Rdb wrote:
> > Okay.  Let me explain a little about how the XML parser I built works.
> >  The basic idea is that has a list of element names which can have
> > child elements.  When it encounters the start tag for one of these
> > elements, it starts building an object.
> > So if there was an xml file like this:
> >
> > <patchbasket>
> > <patch>
> > <author>foo</author>
> > </patch>
> > </patchbasket>
> >
> There's some kind of patch data included, I hope. :) Sysex, maybe?

Of course.  I was keeping it a short as possible since this is just an
example of how the parser works.

> > The parser would:
> > 1) Create a patchbasket object
> > 2) create a patch object
> > 3) Use introspection to find (and call) a setter (in the patch)
> > setAuthor(String) or addAuthor(String)
> > 4) Use introspection to find (and call) a setter in the basket class
> > setPatch or addPatch which will accept the created patch
> > 5) Return the patchbasket object
> >
> Okay... this looks good.
> > Then each IPatch implementation has to have some sort of a
> > write method, plus matching setters.  We should probably have some
> > sort of helper for binary data.  The implementation would look
> > somthing like this:
> >
> > void write(XMLWriter xml) {
> >   xml.writeProperty("author", self.author);
> >   xml.writeBinaryProperty("data", self.sysex);
> > }
> >
> > void setAuthor(String author) { /* ... */ }
> > void setData(String data) { self.sysex =3D XMLTools.decodeBinary(data);=
 }
> >
> I'm a little uneasy by the requirement that the "author" in
> writeProperty has to match the "Author" in "setAuthor". First, you have
> to have two dissimilar items (a hard-coded string "something" in a call
> to writeProperty and a method called "setSomething") that have to match.
> Furthermore, if they don't match, your first indication of a problem
> comes *after* the XML file has been written and you're now trying to
> load it.
>
> The second problem is even worse, though. If *you* write an
> implementation of IPatch... then it would have a write() method. Now,
> suppose that *I* come along and write a subclass your implementation. If
> I want the additional data of my subclass saved, then I also have to
> have a write() method. However, if I do that, then *your* write method
> doesn't get called anymore. I'd either have to go look at your class and
> save all of the data elements that *your* write() method was saving
> (imagine what happens when you add/remove some data elements to your
> class without telling me), or I'd have to call "super.write(xml)" any
> time I wrote a write() method of my own.
>
> Either of those solutions would require that the author of the subclass
> have an awareness of the inner workings of the patch-saving system that
> I'm not convinced should be necessary.

How is requiring a call to the super method an unreasonable awareness
of the inner workings?  Isn't that sort of a standard practice?
Also, subclassing IPatch is something that is not done often and is
complicated. It already requires reading documentation to do it
properly.  So we can just add to the documentation explaining how the
write method has to work with the setters.

> I think we can find a slicker way.

Do you have any suggestions.  I think using introspection to find
which attributes to store would be more confusing to a driver author,
and very tricky to do correctly.
This is just the simplest solution I could think of without writing a
new parser.