The Data Retriever class actually retrieves the data from the remote service. It accepts a series of initialization arguments and contacts the service using the appropriate protocol. Most custom DataRetrievers will be a subclass of one of the standard retrievers:
The DataRetriever class also handles caching and sending the response data to the parser for processing.
Developers would need to write a custom retriever if the service does not use a fixed URL, method (SOAP) or SQL query (database).
There are 2 critical methods that are used by any interface to the data retriever:
These methods generally don’t need to be overridden if you are using one of the standard subclasses.
There are several properties that can affect the behavior of all retrievers:
Retrievers typically are sent the values of a configuration file. There are several values that used by all retrievers to configure the behavior of a particular instance:
Certain subclasses have additional configuration values.
For most cases, you want to subclass an existing standard retriever type (URL, SOAP, Database). But if you want to create your own, then you must implement retrieveResponse which should return a Data Response object. You should consult the documentation for the module to learn what options are set and what additional interfaces need to be supported.
<?php
class MyDataRetriever extends DataRetriever
{
protected function init($args) {
parent::init($args); // you MUST call parent::init()
/* handle a certain config value */
if (isset($args['SOME_CONFIG_VALUE'])) {
$this->doSomething();
}
}
protected function retrieveResponse() {
$response = $this->initResponse();
// do the work to actually get the data
$data = doSomethingToGetData();
$response->setResponse($data);
return $response;
}
}
This is an example for a generic retriever. Subclasses of standard retrievers should be implemented differently. Consult the documentation for each common subclass for more information.