[PATCH V3 1/2] msxml3/tests: Test mxwriter DOMDocument output.
There's a todo_wine on the last assertion because Wine's DOMDocument xml property actually formats the XML nicely, but Windows's does not. So there are newlines and tabs interspersed in Wine's output. Otherwise, the XML appears to match. On 1/23/2021 2:33 AM, Jefferson Carpenter wrote:
Re-submit
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. 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.
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). Should I commit a short test that's correct, or try to get the whole thing right in one go?
On Mon, Feb 1, 2021 at 1:07 PM Jefferson Carpenter < jeffersoncarpenter2(a)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?
On 2/1/2021 10:17 AM, Nikolay Sivov wrote:
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.
All right, how about adding [ local, object, uuid (0636a397-8b61-4180-8d09-90492e27c4fd) ] interface IWineXMLDOMDocumentLock : IUnknown { HRESULT lock(); HRESULT unlock(); } (Assuming lock() and unlock() will suffice for the implementation, otherwise whatever collection of methods does suffice). Is that what you're suggesting? I can take out the attributes too. If there's an application with observable behavior that depends on them, I'll be able to make a bug report.
On 2/1/2021 10:49 AM, Jefferson Carpenter wrote:
All right, how about adding
[ local, object, uuid (0636a397-8b61-4180-8d09-90492e27c4fd) ] interface IWineXMLDOMDocumentLock : IUnknown { HRESULT lock(); HRESULT unlock(); }
(Assuming lock() and unlock() will suffice for the implementation, otherwise whatever collection of methods does suffice).
Is that what you're suggesting?
Or did you mean something else? Sorry, sometimes you say things at such a high level I struggle to understand what you mean. However, I can definitely make the changes you suggested to the test, and I would be fine with implementing the above for the implementation.
participants (2)
-
Jefferson Carpenter -
Nikolay Sivov