Davey Shafik [2004-07-18 18:16 UTC] If you're going to require PHP 5 for this, please use the iterator interfaces (on results) to actually warrant it - otherwise I would suggest moving back to PHP 4.
- Davey
Christian Stocker [2004-07-18 18:25 UTC] Davey, it uses the PHP 5 only Soap Client. At least what I saw in the source code....
Iterators woud be nice, but the package is useful even without it, IMHO.
Jon Wood [2004-07-18 18:35 UTC] I'll look into iterators, however I don't intend to release a PHP 4 version of this just to release Services_Google2 in six months time when everybody gets over the idea that people are going to *use* the new release of PHP.
Klaus Guenther [2004-07-18 18:39 UTC] One thing that PEAR has always offered is a way to do things without php modules. So I would suggest making it possible to search google without the PHP5 SOAP client.
Possibly PEAR Soap would be the right option. It also would perhaps make it possible to use it on PHP4 with minimal changes. The main branch of PEAR SOAP in CVS is php5 only, but I'm not sure of the stability or quality of the code.
Paul Jones [2004-07-18 18:47 UTC] I think this is a valuable addition to PEAR (way to go, Jellybob!)
As others have stated, a PHP4 version would be **very** nice. 6 months is a long time in development terms, so to me, a PHP4 version to be followed by a PHP5 version would not be a bad thing.
For a PHP4 version of a similar pakcage, see S. Bergmann's work at:
http://sebastian-bergmann.de/en/soap_google.php
Jon Wood [2004-07-18 18:48 UTC] Is there really any point in doing SOAP in two different ways?
As far as I know the SOAP extension is one of the defaults, and is definately bundled with the Windows releases.
Martin Jansen [2004-07-18 18:56 UTC] I'm missing any sort of error handling. What happens if the search fails? What happens if the key has expired or is invalid?
Hint: Exceptions.
Jon Wood [2004-07-18 18:57 UTC] The SoapClient object will throw exceptions if anything fails already, and these exceptions have the SOAP error message as their message.
Justin Patrin [2004-07-18 19:01 UTC] You liken this to a database query, but your example code makes it clear that it's not.
I would siggest having query() actually make the call to Google, then have *one* loop with a fetch() that ctually retreives a search result. Fetching subsequent "pages" of results should be the job of this package.
Having a ->numResults() or ->numRows() on the result would be nice as well.
Stephan Schmidt [2004-07-18 19:03 UTC] I'm sorry, but I can't see any use for a package that wraps a SOAP API. Using WSDL, this is done in a few lines of code.
We could then propose Service_* for a lot of websites that offer webservices using SOAP.
Just my 2 cts,
Stephan
Jon Wood [2004-07-18 19:21 UTC] ->fetch() now walks through the result set one item at a time, making new queries as neccesary.
I'm looking into adding ->numResults(), but I'm not sure if the Google API supports it.
Jon Wood [2004-07-18 19:28 UTC] Stephen: If it was a simpler service then I'd agree with you, but having the Google API wrapped with methods to provide easier access to the results seems to make sense.
Hans Lellelid [2004-07-18 20:31 UTC] Cool class.
One option also for iterators, if you want to keep your search vs. iterator API separate would be to use the IteratorAggregate interface; something like:
ServicesGoogle implements IteratorAggregate {
function getIterator() {
return new Services_Google_Iterator($this->runQuery());
}
Klaus Guenther [2004-07-19 16:21 UTC] Just fyi... installed php5 on my windows box and SOAP was not enabled by default. Additionally, the manual states that SOAP must be enabled with --enable-soap for it to be available.
Klaus Guenther [2004-07-19 16:26 UTC] Forgot to mention that php_soap.dll, while physically present in the ext directory is not in the list of extensions in the php.ini file. Also, none of the extensions are enabled by default (in php5 on windows).
Christian Wenz [2004-07-20 06:18 UTC] last time I tried ext/soap, it still had some issues; additionally I do think that PEAR packages should rather rely on PEAR than on PHP packages. So I'd be in favor of using PEAR::SOAP (which would even allow to create a PHP4 and PHP5 version of this package). Just my 2 eurocents.
Justin Patrin [2004-07-20 06:34 UTC] To allow people to use PEAR::SOAP or ext/SOAP, you could quite easily make a simple wrapper for one or the other and have multiple backends, like with the mail package. Same interface for the user, but different backends. No extra *ifs* either, if you use the multiple backends pattern.
IMHO, allowing the user to use PEAR::SOAP would be a good step, but I certainly don't want to rule out the faster C-based ext/SOAP.
|
