#34854 [WFx]: Extend SOAPClient WSDL param to take literal string or local path
| From: | marcus at synchromedia dot co dot uk | Date: | Thu, 13 Oct 2005 11:28:58 +0000 |
| Subject: | #34854 [WFx]: Extend SOAPClient WSDL param to take literal string or local path | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-86523@lists.php.net to get a copy of this message | ||
ID: 34854
User updated by: marcus at synchromedia dot co dot uk
Reported By: marcus at synchromedia dot co dot uk
Status: Wont fix
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5CVS-2005-10-13 (snap)
New Comment:
> Yeah, that's the reason to have a configuration variable.
Well, that's what I'm trying to avoid. The issue is really
that SOAPClient's local path support acts differently from
nearly every other use of local paths. The WSDL is part of
my class library, but I can't treat it as such because I
can't rely on it being found.
If not include_path, then accepting a literal string
containing the WSDL data would be a good substitute, and
would also work well in cases where the WSDL is held in a
local DB.
Previous Comments:
------------------------------------------------------------------------
[2005-10-13 13:16:23] tony2001@php.net
>Because for any given deployment, the absolute path may be
different.
Yeah, that's the reason to have a configuration variable.
I honestly don't see a reason for SOAPClient to use include_path.
So it's a "Won't fix".
------------------------------------------------------------------------
[2005-10-13 13:12:54] marcus at synchromedia dot co dot uk
Because for any given deployment, the absolute path may be
different, simply because some servers put stuff in different
places, or because it's in a different virtual host etc. Both
of those situations are normally handled using the include
path, but in this case we're denied that possibility.
------------------------------------------------------------------------
[2005-10-13 13:03:28] tony2001@php.net
>I'm having to copy my WSDL files into every
>place that my class library is called from because the URL
>resolution will only ever look in the calling directory and
>not in the include path that allowed it to find my classes.
Why not to use absolute path then?
------------------------------------------------------------------------
[2005-10-13 12:58:10] marcus at synchromedia dot co dot uk
Description:
------------
This is a minor thing that's been troubling me, making it
difficult to deploy a salesforce.com SOAP client across
multiple projects. Salesforce is a particular interest
because its WSDL files are not available directly online -
you have to download and save local copies manually.
When constructing a SOAPClient object, the WSDL parameter
provided is treated like a URL (because it will usually BE a
URL). For 'local' URLs, it searches the current directory,
including any relative path that it uses. However, because
it is fundamentally a URL and not a file request like an
include, it does not search the include path. The net result
of this is that I'm having to copy my WSDL files into every
place that my class library is called from because the URL
resolution will only ever look in the calling directory and
not in the include path that allowed it to find my classes.
An alternative would be to allow providing the WSDL as a
literal string, probably read using file_get_contents()
which does support using the include path.
A worse solution is to provide the WSDL contents as the
response to a separate HTTP call (i.e. act like the WSDL is
online after all). This would work, but it's way less
efficient. It's also hard to configure across multiple
installations.
I can't use an absolute path as it's deployed in multiple
configurations on multiple servers, and config is bad enough
already.
So, please can you either extend the WSDL parameter to
accept a literal string or a local path that's not handled
as a URL.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=34854&edit=1