[PATCH V3 1/2] msxml3/tests: Test mxwriter DOMDocument output.

[Nikolay Sivov]

On Mon, Feb 1, 2021 at 1:07 PM Jefferson Carpenter <
jeffersoncarpenter2 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210201/d07e8ba8/attachment-0001.htm>