Hi,
I really wasn't subscribed. :)
1. I take only a very short look into the patch, but didn't understand that
it does.
I will make more careful look on next week.
Your explanations and PHP examples (tests) would be very useful.
2. __setHeaders() - can be easily implemented in PHP itself:
<?php
class CleverSoapClient extends SoapClient {
private $headers = null;
function __setHeaders($headers) {
$this->headers = $headers;
}
function __call($function, $args) {
return $this->__soapCall($function, $args, null, $this->headers);
}
}
$client = new CleverSoapClient(...);
$client->__setHeaders(new SoapHeader(...));
$client->GetUser(...);
?>
I didn't test this example, but similar code worked fine.
Thanks. Dmitry.
> -----Original Message-----
> From: George Schlossnagle [mailto:george@omniti.com]
> Sent: Saturday, March 19, 2005 00:48
> To: Adam Maccabee Trachtenberg; dmitry@php.net
> Cc: George Schlossnagle; soap@lists.php.net
> Subject: Re: ext/soap handing of header params
>
>
> Here's my patch that seems to address the issue via my version of
> solution b). Seems to work with the Sabre API for me. I await
> comments and approval (from Dmitry) to commit:
>
> http://sanni.omniti.com/soap_header.diff
>
>
>
> On Mar 18, 2005, at 12:29 PM, Adam Maccabee Trachtenberg wrote:
>
> > On Fri, 18 Mar 2005, George Schlossnagle wrote:
> >
> >> these binding.operation.input.header blocks are currently
> >> a) entering the proxy classes call prototype
> >> b) not being put into the actual soap envelope as headers
> but as body
> >> nodes.
> >>
> >> This is clearly broken. As I see it one of two things
> need to occur:
> >>
> >> a) drop the header params from the proxy class's method
> prototype and
> >> require they be set by hand. (ick, imho)
> >> b) have php correctly integrate them into the request as headers.
> >
> > I would prefer (b). I do a lot of (a) right now, which I don't like
> > because it's, well, ick.
> >
> > The one redeeming quality is that once I've built up the
> header, I can
> > stash it someplace and ignore it. What I dislike is that I can no
> > longer use the overloaded method syntax (because there's no
> way to set
> > headers, only parameters), so I'm forced to do:
> >
> > $user = $client->__soapCall('GetUser', array($params),
> NULL, $header);
> >
> > Instead of:
> >
> > $user = $client->GetUser($params);
> >
> > (I think I can probably work around this by subclassing
> SOAPClient and
> > doing some __call() magic of my own, but it's not the best solution,
> > IMHO.)
> >
> > In my ideal world, I would be able to do something like:
> >
> > $client = new SOAPClient('foo.wsdl');
> $client->__setHeaders($headers);
> > $client->GetUser($params);
> >
> > I think trying to have ext/soap figure out what values are SOAP
> > headers and what are SOAP parameters may require a little too much
> > magic. (And what happens when a header and a parameter have the same
> > name?)
> >
> > Also, I generally find I set the headers once per client
> and then make
> > multiple client calls without modifying them, so a "set it once and
> > forget it" method works best in this situation.
> >
> > How does this sync up with what you're thinking?
> >
> > -adam
> >
> > PS: Dimity @ Zend does almost all of the ext/soap work, but I never
> > see him on this list.
> >
> > --
> > adam@trachtenberg.com | http://www.trachtenberg.com
> > author of o'reilly's "upgrading to php 5" and "php cookbook"
> > avoid the holiday rush, buy your copies today!
> >
> > --
> > PHP Soap Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> George Schlossnagle
>
> -- Prinicipal Consultant
> -- OmniTI Computer Consulting
> -- http://www.omniti.com
>
>
--
PHP Soap Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
