27 Jan
27 Jan
2:39 a.m.
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
1 Feb
1 Feb
9:36 a.m.
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.
10:07 a.m.
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?
10:17 a.m.
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:
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.
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?
10:49 a.m.
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.
11:10 a.m.
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.
1203
days inactive
1212
days old
6 comments
2 participants
participants (2)
-
Jefferson Carpenter -
Nikolay Sivov