thank you for your response
I've published the code here
https://github.com/muayyad-alsadi/php-lite-solr
1) I'd recommend that you use HTTP_Request2 for communicating with the
Solr server.
the curl HTTP client I'm using is very important for the following reasons
1. it's minimal (by using __call) yet powerful (thanks to curl)
2. it support custom HTTP methods
3. although it's <100 lines (most of them comments) yet it does not have
any kind of limitation
Another is that people can set different UserAgent strings if they are
required to.
they can, as you can see the constructor accepts a $options parameter which
overrides the default _$opt
like this
$http=new HttpClient(array(CURLOPT_USERAGENT=>'LiteSolr (cUrl)'));
2) Implied from above, unit tests would be a nice addition.
I now the importance of unittest
I'm not sure how can we unittest a client (it requires running java solr
..etc.)
4) Your code doesn't quite gel with the PEAR Coding Standards. Using the
PHP_CodeSniffer's cli tool phpcs will highlight what would need to be
changed. It may be possible to set your editor/IDE to automatically adjust
your code so you need to make few, if any, manual changes.
I'll do that, but you can help any time by forking and doing a pull request
5) I've noticed a few uses of var_dump in your code. If it is your intent
to retain them for informational purposes, I'd suggest implementing an
Observer pattern so that such output only happens when and as required.
they used to be part of the documentation,
they are moved to README.md
6) I'd seperate your example usages out to a separate file, perhaps
examples/example_1.php for example.
answered above
There is a formal process for proposing new PEAR Packages, outlined at
https://pear.php.net/manual/en/newmaint.proposal.php that you should follow.
That said, I've given a brief look over your code, but I've a few
suggestions none-the-less.
1) I'd recommend that you use HTTP_Request2<https://pear.php.net/package/HTTP_Request2/>for communicating with the Solr server.
The main advantage of this is that you can then mock communications for
unit testing. Another is that people can set different UserAgent strings if
they are required to. One such example of another PEAR package utilising
HTTP_Request2, though there are many, would be the Services_OpenStreetMap
package at https://pear.php.net/package/Services_OpenStreetMap. Others
are listed at the bottom of https://pear.php.net/package/HTTP_Request2.
2) Implied from above, unit tests would be a nice addition.
3) From a naming Point-Of-View, as this is neither a low-level HTTP nor
networking component, I'd recommend that it sit in the Services category so
naming it something like Services_Solr or Services_SolrLite comes to mind.
Personally, I'd be inclined to name it so the emphasis is on Solr, not Lite.
4) Your code doesn't quite gel with the PEAR Coding Standards. Using the
PHP_CodeSniffer's cli tool phpcs will highlight what would need to be
changed. It may be possible to set your editor/IDE to automatically adjust
your code so you need to make few, if any, manual changes.
5) I've noticed a few uses of var_dump in your code. If it is your intent
to retain them for informational purposes, I'd suggest implementing an
Observer pattern so that such output only happens when and as required.
6) I'd seperate your example usages out to a separate file, perhaps
examples/example_1.php for example.
Hope this helps,
Ken
Post by Muayyad AlSadihi,
I would like to propose a new php solr client
sample code is found here
https://gist.github.com/muayyad-alsadi/5648629
I'm asking about package name, file names and class names
and directory structure ..etc.
should it be called
Net_LiteSolr/LiteSolr.php
Net_LiteSolr/Http.php
--
http://blogs.linux.ie/kenguest/