Move Apache_Solr_Service->_documentToXmlFragment to Apache_Solr_Service->__toString

[GoogleCodeExporter]

Move the responsability of the XML generation to the document, so you can enjoy 
this feature outside of the scope of Apache_Solr_Service

<?php
require_once 'Apache/Solr/Document.php';

$doc = new Apache_Solr_Document();
$doc->setBoost(1.5);
$doc->addField('field1', 'a');
$doc->addField('field1', 'a');
$doc->setFieldBoost('field1', 2.5);
$doc->addField('field2', 'b');
echo $doc; // Produces: <doc boost="1.5"><field name="field1" 
boost="2.5">a</field><field name="field1">a</field><field 
name="field2">b</field></doc>

Original issue reported on code.google.com by julien.b...@gmail.com on 24 Apr 2012 at 11:35

Attachments:

• [Apache_Solr_Document - toString.patch](https://storage.googleapis.com/google-code-attachments/solr-php-client/issue-76/comment-0/Apache_Solr_Document - toString.patch)

[GoogleCodeExporter]

Apache_Solr_Service::_documentToXmlFragment(...) is an implementation detail, 
which is why its not a public method. If we decided it was faster to use the 
csv update handler to add documents, this method might go away and users using 
only public API would not care.

So that's my reasoning for how it is, now I want a real use case for your 
change. I want to see what benefits it can give to users.

Original comment by donovan....@gmail.com on 24 Apr 2012 at 3:29

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I get your point, 

can then rename __toString() to toXml() and use __toString() as a convenient 
proxy;
when switching to a CSV format, just switch to a not yet implemented toCsv() 
method in Apache_Solr_Service->addDocuments().

providing the XML output feature on its own, outside the Apache_Solr_Service 
class, is the actual point.
It is also useful for debugging when you want an XML view of a 
Apache_Solr_Document which is more readable than a var_dump($document);

Original comment by julien.b...@gmail.com on 24 Apr 2012 at 3:55