Alezra
Di-Tron Heavy Industries
Atlas Alliance
   |
Posted - 2008.12.05 03:38:00 -
[1]
I built a framework for a similar API interface and I'm guessing it operates in a similar fashion to Relyen's. The whole thing is broken out into different objects (perhaps even excessively.) The base class is apiConnection. Its only purpose is to connect to the API using the supplied arguments and handle caching data.
The individual data classes are supplied with a reference to an apiConnection object which they use to fetch xml.
An example of my api in action:
$myAccount = new apiConnection($userID, $apiKey);
$myData = new apiData();
$myData->char->SkillInTraining->fetch($myAccount, $characterID);
$xml = $myData->char->SkillInTraining->getRawXML();
It can generically retrieve the xml for any api call at the moment. The next part of implementation would be to cause the data fetch() method to parse the xml into usable content. I realized that I could literally copy the code out of your parsing functions directly into my data objects. I'm still debating if I want to do that or write my own xml parsing.
The constructor for the apiConnection class looks like this:
public function __construct ($id = 0, $key = 0, $setCaching = TRUE,
$dir = "xmlcache/", $rootAddress = "http://api.eve-online.com")
If caching is enabled (which it is, by default) then all data retrieved from the api is stored under
xmlcache/$userID/$characterID/
A call to flushCache() will delete that data, and a fetch command with the flag FLUSH_CACHE will force the apiConnection to query the server again.
|
Alezra
Di-Tron Heavy Industries
Atlas Alliance
|
Posted - 2008.12.10 03:11:00 -
[2]
Ehrm, well I was planning on releasing it eventually, but to be honest at the moment it isn't terribly impressive. I have about 55 lines of useful code that handle the apiConnection->fetch() and caching and then 600 lines of code that do nothing but build empty data handlers. As an example, for each API call there's a class like this:
class skillTrainingData extends genericData
{
public function __construct($url)
{
parent::__construct($url);
}
}
Eventually I want to add an xml parser and accessors to each of these class definitions, but it's a bit daunting. At the moment the only thing each data object does is construct, fetch and getRawXML (which are all members of genericData.)
My strategy would be to do something like have an abstract function parse() in each data member that's called when fetch() is ran. The parse command for SkillTrainingData runs an xml parser and stores the results in public variables. Then the user can call something like
$myData->char->SkillInTraining->fetch();
$currentSkill = $myData->char->SkillInTraining->typeID;
$nextLevel = $myData->char->SkillInTraining->trainingToLevel;
|