On Mon, Feb 1, 2021 at 1:07 PM Jefferson Carpenter < jeffersoncarpenter2@gmail.com> wrote:
On 2/1/2021 9:36 AM, Nikolay Sivov wrote:
This seems to be correct in assumption that document output is treated separately. Quick testing shows that it's using some internal interface that the document object implements. It might be used to lock/unlock document while writer is populating it.
Ok, sorry to change the topic / scope but do you think it would be better to write a custom class that implements IXMLDOMDocument (and IDispatch) and pass that to the mxwriter instead of instantiating a DOMDocument? That is, do it like test_saxreader.
I think that's better because then we could gain some visibility into what interfaces the Microsoft msxml queries for, and how it locks and unlocks the document.
I'll do it that way in the next version, and use call_entry / call_sequence structs like the saxreader tests.
So to improve the tests I think it
would be interesting to see if written nodes appear right away on SAX calls, and if modifying methods of IXMLDOMDocument are indeed disabled during this process. Another case that's not tested is writing to
non-empty
document. Also you can remove the part that uses attributes, I don't
think
it's valuable.
Also, by checking that the correct call sequences are invoked by mxwriter, the nodes would appear right away by virtue of a correct wine DOMDocument implementation. (If they don't, that's a domdoc.c patch).
No, I don't think you should do a full match of calls that are made. It would be enough to introduce some private interface for now, and reject external document implementations. It does not have to be a COM interface.
Should I commit a short test that's correct, or try to get the whole thing right in one go?