New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessing generated XML #29

Open
ryanhellyer opened this Issue Aug 24, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@ryanhellyer

ryanhellyer commented Aug 24, 2015

Is there any way to get the raw XML output (for debugging purposes)? I have a bug, but can't work out where and am hoping that having access to the raw XML before it's sent to the other server (ie: the output from will be helpful.

@ryanhellyer

This comment has been minimized.

Show comment
Hide comment
@ryanhellyer

ryanhellyer Aug 24, 2015

I found that this was possible by adding print_r( $this->payload );die; at line 2189 of the xmlprc.inc file. It would be useful to have a way to see the ouput without hacking up the core library files like that though.

ryanhellyer commented Aug 24, 2015

I found that this was possible by adding print_r( $this->payload );die; at line 2189 of the xmlprc.inc file. It would be useful to have a way to see the ouput without hacking up the core library files like that though.

@gggeek

This comment has been minimized.

Show comment
Hide comment
@gggeek

gggeek Aug 25, 2015

Owner

Well, the $payload member of the Message is public, so you can access it at any time you want. You can dump it in your own code, before calling send() on the Client, so it is not a hack.

If you turn on the $debug in the client, you also get a lot of info. Especially when using the server from this library, which can echo back encoded in comments in the xml response the full payload it received. You can see this in action when using the built-in debugger and cranking up the debug level in the bottom-half of the main form. You could f.e. point your own code at the built in server, and dump what you get back => the request sent will be part of the response.

I was recently thinking about making the client able to write its requests to a file pointer instead of a network socket, explicitly to ease debugging not only of the message payload, but of the whole request, including http headers.
This was not done yet because it just does not fit too well in the current API - f.e. it would not work at all as soon as you are setting up the client to use curl instead of fsockopen (and you do not do this explicitly, rather implicitly most of the time).
Last but not least, it should also allow dumping the received payload, otherwise it would not be catering to 50% of debugging needs.

I might otoh add a chapter in the doc where I explain how to use a network sniffer to achieve exactly the same :-)

Owner

gggeek commented Aug 25, 2015

Well, the $payload member of the Message is public, so you can access it at any time you want. You can dump it in your own code, before calling send() on the Client, so it is not a hack.

If you turn on the $debug in the client, you also get a lot of info. Especially when using the server from this library, which can echo back encoded in comments in the xml response the full payload it received. You can see this in action when using the built-in debugger and cranking up the debug level in the bottom-half of the main form. You could f.e. point your own code at the built in server, and dump what you get back => the request sent will be part of the response.

I was recently thinking about making the client able to write its requests to a file pointer instead of a network socket, explicitly to ease debugging not only of the message payload, but of the whole request, including http headers.
This was not done yet because it just does not fit too well in the current API - f.e. it would not work at all as soon as you are setting up the client to use curl instead of fsockopen (and you do not do this explicitly, rather implicitly most of the time).
Last but not least, it should also allow dumping the received payload, otherwise it would not be catering to 50% of debugging needs.

I might otoh add a chapter in the doc where I explain how to use a network sniffer to achieve exactly the same :-)

@gggeek

This comment has been minimized.

Show comment
Hide comment
@gggeek

gggeek Sep 1, 2015

Owner

ps: as a side note: you really should use the latest version of the code (branch 4.0) if you are starting a new project, not the old one. It is currently tagged alpha, but the stability is not worse than the 3.0 release.

Owner

gggeek commented Sep 1, 2015

ps: as a side note: you really should use the latest version of the code (branch 4.0) if you are starting a new project, not the old one. It is currently tagged alpha, but the stability is not worse than the 3.0 release.

@gggeek gggeek added the enhancement label Oct 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment