> This sounds more then a bit weird to me; the suggestion moves quite a bit
> away from the DOM design in requiring the caller to have more knowledge
> about implementation of the dom-library.

Correct. That's why I don't intend to use it for the final phase, but
only as intermediate step because even the loading code can't be
hooked into normal QDom classes but rather in outside class. Note that
this is not even practical, one has to pass this additional "holder"
object every time (and looking at kofficecore, it's just almost
everywhere).

> From your reply I gather that you intend to develop this API and testing
> it in, for example, kspread.

Yes, roughly in this track.

> I don't think that is a good idea as it will take too much time and the
> loading can not test all corner cases of the API.  I suggest you write
> some unit tests that comes with an XML file to test all ideas and corner
> cases in it.

Of course I won't rely only on such loading code. As a matter of fact,
I even just started without on-demand loading first so that I have a
solid ground as reference.

> Expanding the tests and xml file(s) as your implementation grows more
> mature.

Exactly what I'm doing. I have already more than 500 CHECKs and it
still keeps growing :-P

Best regards,

--
Ariya Hidayat, http://ariya.blogspot.com
http://www.google.com/search?q=ariya+hidayat&btnI
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel