open All Channels
seplocked EVE Technology Lab
blankseplocked Pheal - a new, simple to use PHP5 API Library
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2 3

Author Topic

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.03 15:15:00 - [1]
 

Hello everyone,

during the last few days i had a look at the available PHP API Libraries,
and well decided i'd be better of porting my Ruby Library (EAAL) to PHP.

so i did (mostly last night), and now its time for a first release.

you can get the library at github,
you will also find a little bit of documentation there.

a few more words why i wrote this instead of using Yapeal or Ale, you can find
in my Blog.

Hint: While the library works alone, it integrates very well in King23
(the framework i used for building northern-crusade).

best regards,
PP

PS: you can find a page about it on the eve-dev wiki too.

Qoi
Exert Force
Posted - 2010.06.03 20:16:00 - [2]
 

Looks very solid, thank you very much for sharing it Very Happy

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2010.06.04 01:56:00 - [3]
 

I haven't taken the time to look at it, but I'll see if it works better for some of my projects. I think you kind of miss the point of yapeal. Its not really a library in the traditional since. Most projects are going to take data from the API, do what ever, then that data ends up in a database. Yapeal skips directly to putting the data into a database. I do agree that documentation could be better.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 08:29:00 - [4]
 

Originally by: Johnathan Roark
I haven't taken the time to look at it, but I'll see if it works better for some of my projects. I think you kind of miss the point of yapeal. Its not really a library in the traditional since. Most projects are going to take data from the API, do what ever, then that data ends up in a database. Yapeal skips directly to putting the data into a database. I do agree that documentation could be better.


i dont think that invalidates anything i said. Even with that goals it should be configureable through Code,
not by ini only, and well, putting direct in the database means you have to fetch from there, process the data,
and then put it down in the way you need it, its quite unlikely applications will use the data the way yapeal
stores it. (and if, then i dont want to be the one optimizing it for higher loads :p)

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2010.06.04 09:09:00 - [5]
 

Quote:
Even with that goals it should be configureable through Code, not by ini only ...
The only things that are in the ini is the DB user/password stuff (can't store them in the DB since they are needed to access it Wink) and stuff dealing with logging and caching which really doesn't need to be configure by anyone but the developer using it as a library in their application. Everything else is configured and stored in the DB util tables and Yapeal includes helper classes to manage them.

Quote:
... putting direct in the database means you have to fetch from there, process the data, and then put it down in the way you need it
You're doing something wrong if you're trying to store the data again outside the DB instead of using it directly through selects with joins etc as needed. If you're not use to DBs, which I wasn't really until a couple projects ago, you try doing stuff like that instead of letting the DB work for you. Once I learned how they can help you for things like this I'd never go back but I also know they aren't for every project either.

In the end it all depends on the application. For people use to developing 2-3 tier web applications Yapeal is a better fit. For simple one tier ones like your talking about what you've made works well and the project that Yapeal grow out of had much the same idea but in the end didn't scale well until it move to something with a database and the more modern multiple tier model. There's always room for other ideas how to do things and hopefully some people will find Pheal useful for them in some of their projects just like many people have found Yapeal and ALE to be in many others.

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.06.04 10:28:00 - [6]
 

Edited by: Catari Taga on 04/06/2010 10:30:09
Originally by: Dragonaire
Quote:
... putting direct in the database means you have to fetch from there, process the data, and then put it down in the way you need it
You're doing something wrong if you're trying to store the data again outside the DB instead of using it directly through selects with joins etc as needed.

I don't want to get involved in your library wars but I wanted to comment on that one.

Storing (i.e. caching) data structured in the way your application needs it is always going to be faster than querying from several tables in a database, so there is absolutely nothing wrong with doing that. Querying the database is just a convenience that saves you time to set up proper caching, or in case of fast changing input data it may be a necessity (generally not with the API, though, since it enforces caching).

Add a library to that, which is what he commented on, and you're adding several levels of complexity, disk accesses and many processing cycles used and then your application will still have to do the work it would have had to do without the library, anyway.

Libraries are a convenience, they make coding faster, never your application.

PS: I love all your libraries, don't shoot me. Very Happy

Amida Ta
German Mining and Manufacture Corp.
Posted - 2010.06.04 12:10:00 - [7]
 

Edited by: Amida Ta on 04/06/2010 12:11:06
Originally by: Catari Taga

Libraries are a convenience, they make coding faster, never your application.


I'd not support that as a general statement.
E.g. EveAI supports a (configurable) complete memory-representation of data. It's not possible to be faster than this regardless if you do it yourself or by hand. The difference is that when you do it yourself it costs lots of time which you then don't have to optimize. So for a sufficiently large (and good) library the library is not only going to make coding faster but also your application.
If that wouldn't be true then you should try to develop your own language and own operating system.
However I doubt that you (yourself) could develop an OS that is faster than any of the mainstream existing OSes for exactly the same reasons I mentioned above. So using an existing OS is not only (much) more convenient, its also faster.

P.S. From a purely theoretical point of view (ignoring time completely) you would be right.

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.06.04 12:32:00 - [8]
 

Leaving question of my ability to code an operating system aside, which is besides the point (we are discussing special purpose vs. do it all code, special purpose will almost always be more efficient, even or in particular on OS level), I think I had coding time factored in in my statement, therefore I do not think we disagree - at least I do not disagree with what you said and yet I still stand by my statement.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 13:09:00 - [9]
 

Originally by: Dragonaire
The only things that are in the ini is the DB user/password stuff (can't store them in the DB since they are needed to access it Wink) and stuff dealing with logging and caching which really doesn't need to be configure by anyone but the developer using it as a library in their application.


As a developer using it as a library i am not supposed to know how the database setup, or the pathes for caches are at the users side.
i do want to offer the user a way to configure it, but i do not want him to edit ini files of libraries that he does not need to know about.


Originally by: Dragonaire
You're doing something wrong if you're trying to store the data again outside the DB instead of using it directly through selects with joins etc as needed. If you're not use to DBs, which I wasn't really until a couple projects ago, you try doing stuff like that instead of letting the DB work for you. Once I learned how they can help you for things like this I'd never go back but I also know they aren't for every project either.

Cached data does not belong in the database, unprocessed data, which is stored processed in the database does not need to be there either,
no point in having double the amount of data arround.
Data that does not need to be processed at all - well can be served directly from the cache, being much faster than using a database inbetween.

Originally by: Dragonaire
In the end it all depends on the application. For people use to developing 2-3 tier web applications Yapeal is a better fit.

No.
Originally by: Dragonaire
For simple one tier ones like your talking about what you've made works well and the project that Yapeal grow out of had much the same idea but in the end didn't scale well until it move to something with a database and the more modern multiple tier model. There's always room for other ideas how to do things and hopefully some people will find Pheal useful for them in some of their projects just like many people have found Yapeal and ALE to be in many others.

i was not talking of any "simple one tier" applications at all, except you want to call the code snippets i provided as documentation "applications".

And as soon as the data you serve gets more complex, the last thing you want todo is serve complex joins straight from the database. You serve them through various ways of caching, or you kill you whole setup.

Amida Ta
German Mining and Manufacture Corp.
Posted - 2010.06.04 13:15:00 - [10]
 

Originally by: Catari Taga
we are discussing special purpose vs. do it all code, special purpose will almost always be more efficient, even or in particular on OS level

20 years ago (when we had procedural code that was fully compiled down to raw CPU instructions) I would have completely agreed to this. But today this is just not true anymore.
One example from .Net: .Net has generic use-for-everything collections (can be used for any type). Now say you want a specific collection for int. You can write the complete code on your own, but your special IntList will NEVER be faster than a generic List<int>. In the best case your self-written code will be just as efficient as the general-purpose one.
Or in EveAI if you need Blueprints for Products thats a single memory read. It's impossible to be more efficient than that. No matter how special-purpose your code is.
I'm not saying that it's impossible that special purpose code is more efficient than other code. In fact it sometimes will be A LOT more efficiently. But as a general statement that's not true (any longer).

Catari Taga
Centre Of Attention
Middle of Nowhere
Posted - 2010.06.04 13:31:00 - [11]
 

Amida Ta, please don't take this wrong, but I feel this argument is going nowhere and I don't want to derail this thread further while we haggle about semantics. I'll be happy to carry this on in game or another thread if you want but I'll stop in this one.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 13:45:00 - [12]
 

Originally by: Amida Ta

Or in EveAI if you need Blueprints for Products thats a single memory read. It's impossible to be more efficient than that. No matter how special-purpose your code is.


Is it?, even if i have a list of products,
an exclusion list of products, and only need those that
are not excluded with blueprints, but need all of 'em to be in my object tree?
if this is one read, then i end up either with data that i dont use (using your generic implementation),
or i do a specialised solution which removes the excluded ones from the ones requested,
in a low-product count this specialised solution might add overhead, but in an environment
with alot of data trading of the few cycles for having less memory usage might be the more efficient way.

either way, Catari Taga is right, this discussion does not belong into my thread,
so lets keep it out of here.

Amida Ta
German Mining and Manufacture Corp.
Posted - 2010.06.04 14:46:00 - [13]
 

Originally by: Peter Powers
Originally by: Amida Ta

Or in EveAI if you need Blueprints for Products thats a single memory read. It's impossible to be more efficient than that. No matter how special-purpose your code is.


Is it?, even if i have a list of products,
an exclusion list of products, and only need those that
are not excluded with blueprints, but need all of 'em to be in my object tree?
if this is one read, then i end up either with data that i dont use (using your generic implementation),

As you asked:
This can't be one memory read (which is limited to 32/64bits data/pointer on a 32/64bit system) anyways. Moreover EveAI doesn't have ANY build in way for building sublists anyways. Thats part of the .Net framework classes that EveAI uses and will be done by the user of the library. And for those using the .Net framework ones will again me more efficient than coding the list-selection yourself.

But as requested lets rest this topic on your thread.

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2010.06.04 16:55:00 - [14]
 

Quote:
As a developer using it as a library i am not supposed to know how the database setup, or the pathes for caches are at the users side.
i do want to offer the user a way to configure it, but i do not want him to edit ini files of libraries that he does not need to know about.
Right so you offer the option to configure them along with anything else you let your end users change in your application and you handle updating the ini file inside the application because they don't care what part of the code you are using needs it.

Quote:
Cached data does not belong in the database, unprocessed data, which is stored processed in the database does not need to be there either, no point in having double the amount of data arround.
I agree that if you already have it in a preprocessed/full processed state you really don't need to store the raw data too but as I found out lots of people wanted the XML cached where they could get at it so listening to my users (the application developers) I give them the option to cache the XML as files or in the DB but it's not required for Yapeal to work and can be turned off if not wanted.

Quote:
Data that does not need to be processed at all - well can be served directly from the cache, being much faster than using a database inbetween.
If you are showing the XML directly to the user than that is true but I'm guessing you aren't doing that Wink Are there times when it's easier and faster to use the data straight from the XML say into HTML page absolutely but once you have to start translating all those wonderful TypeID numbers etc into names and pictures in your application using the static data dump from a DB it makes more sense to combine the API data from a DB table with it than having to process the XML on every page refresh for hundreds or thousands of items. Are there ways to do it so you don't have to do that yes but once you start coding things to do that you're starting to duplicate in you application things that have already been solved by other people in all the exist caching libraries for PHP, in the web server or in effect making your own custom DB server. Just as was discussed earlier in this thread that can be a better/faster way of doing things but often there are better uses for your time as well.

Quote:
No.
???

Quote:
And as soon as the data you serve gets more complex, the last thing you want todo is serve complex joins straight from the database. You serve them through various ways of caching, or you kill you whole setup.
I agree and was in effect saying much the same thing above. Simple joins on tables with good indexes don't take any extra time. If that wasn't true why would DBs have been developed to start with Wink

You've developed Pheal/EAAL for an application/framework you've made which is much the way the code that became Yapeal started out as in an application I developed for my corp. So it was a solution to a need you had which is good and it seems you took some time to make it in a way that allowed it to be translated fairly easily from Ruby to PHP which is great Smile You seem to have even made it in a general enough way that others might be able to use it as well but I'll bet the chances are once people do start using it in ways you never thought of yourself you'll find changes will need to be made. Yapeal has been doing that every since I made it public over a year ago and continues to change as the APIs and the applications it is used in grow and change as well. If anyone had told me how it would grow and change when I started and the amount of time I would spend on it I probably wouldn't have believed them or might not have even started the project Very Happy I'm glad I did but it's really something to look back at where it came from to what it is today and hopefully you have the same great experience happen for you with Pheal.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 19:18:00 - [15]
 

Edited by: Peter Powers on 04/06/2010 19:18:36
Originally by: Dragonaire
Right so you offer the option to configure them along with anything else you let your end users change in your application and you handle updating the ini file inside the application because they don't care what part of the code you are using needs it.


right, because writing a config file through the application is much more efficient, than using configuration which the application needs anyways.
If i for example use a database, then i dont want it to be configured in two places,
i want my frameworks / applications database connection data, and IF i'd agree (which i dont) with an API library writing to the database (yeah, a data import library which writes to the database directly not using my model...), then i would want my application to directly tell the library what todo, not write an additional file.

Originally by: Dragonaire
I agree that if you already have it in a preprocessed/full processed state you really don't need to store the raw data too but as I found out lots of people wanted the XML cached where they could get at it so listening to my users (the application developers) I give them the option to cache the XML as files or in the DB but it's not required for Yapeal to work and can be turned off if not wanted.


Still yapeal requires acces to a database.

Originally by: Dragonaire

Originally by: Peter Powers
Data that does not need to be processed at all - well can be served directly from the cache, being much faster than using a database inbetween.
If you are showing the XML directly to the user than that is true but I'm guessing you aren't doing that

No, thats why i said data that doesnt need to processed, and as i said in my statement before that, i personally think that a proper application will process the data,for example to put it in a format that fits the model.
Originally by: Dragonaire
once you have to start translating all those wonderful TypeID numbers etc into names and pictures in your application using the static data dump from a DB it makes more sense to combine the API data from a DB table with it than having to process the XML on every page refresh for hundreds or thousands of items.


Yes, and thats the job of the model layer of the application, not of some data importer which has no clue at all how that Model looks.
Originally by: Dragonaire
Are there ways to do it so you don't have to do that yes but once you start coding things to do that you're starting to duplicate in you application things that have already been solved by other people in all the exist caching libraries for PHP, in the web server or in effect making your own custom DB server.

you are not making any sense here, there is no existing "cache library", "web server" or "db server", which has the model logic of a new application, except you have a shared model for several applications.
Originally by: Dragonaire

Originally by: Peter Powers
No.
???

i think the reason why it is NOT a good idea to use a library which comes with its own database access, its own table layouts etc. is that in modern application you want a proper model.


Originally by: Dragonaire
I agree and was in effect saying much the same thing above. Simple joins on tables with good indexes don't take any extra time. If that wasn't true why would DBs have been developed to start with
pretty much because a unified way is needed to access relational data. That said, you might want to look at alternative object/document based databases, which are currently having a nice upwards trend, since they are much more efficient in storing object/document style data than most rdbms+orm based solutions.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 19:23:00 - [16]
 

Originally by: Dragonaire

You've developed Pheal/EAAL for an application/framework you've made which is much the way the code that became Yapeal started out as in an application I developed for my corp. So it was a solution to a need you had which is good and it seems you took some time to make it in a way that allowed it to be translated fairly easily from Ruby to PHP which is great

I wrote EAAL in 2008 to learn ruby, and because i wanted a library which needed very little maintenance when new pages where added to the EVE API. EAAL since then has been used for various applications, and seen contributions by several developers. At no point in the development of EAAL there was even a thought about if/how this could be ported to PHP.
Why it was ported is outlined in my Blog - because there simply was no PHP Library which would work as flexible as Pheal or EAAL do for PHP. (For Python Entity wrote an awesome library which works quite similar, long before i ever looked at python, and long before i wrote EAAL).

Originally by: Dragonaire

You seem to have even made it in a general enough way that others might be able to use it as well

it was designed to stand alone, and integrate well in all sorts of environments, you use PHP5.2 in a default setup? it works, without additional libraries etc.
Originally by: Dragonaire
but I'll bet the chances are once people do start using it in ways you never thought of yourself you'll find changes will need to be made.

Changes that would need to be made would be if the way the EVE API works. Stuff like writing to a database, or other cache handlers can and should simply be done userland, by design.



Originally by: Dragonaire
Yapeal has been doing that every since I made it public over a year ago and continues to change as the APIs and the applications it is used in grow and change as well.

EAAL and Pheal are designed to NOT need changes when CCP adds new pages to the API, thats one of the design goals, and it works for EAAL quite well (and will for Pheal too). Its one of the things that i think where missing in Yapeal or Ale.

Lumy
Minmatar
Sebiestor Tribe
Posted - 2010.06.04 19:29:00 - [17]
 

Edited by: Lumy on 04/06/2010 19:34:51
Originally by: Peter Powers

right, because writing a config file through the application is much more efficient, than using configuration which the application needs anyways.
If i for example use a database, then i dont want it to be configured in two places,
i want my frameworks / applications database connection data, and IF i'd agree (which i dont) with an API library writing to the database (yeah, a data import library which writes to the database directly not using my model...), then i would want my application to directly tell the library what todo, not write an additional file.

...


And that's why Ale allows you to pass it active database connection. Something like this:
$db = mysql_connect(...);
$ale = AleFactory::getEVEOnline(array('cache.db' => $db));

For what it matters, you can define/override any value from config file in same way.

Just saying... Twisted Evil

Originally by: Peter Powers
EAAL and Pheal are designed to NOT need changes when CCP adds new pages to the API, thats one of the design goals, and it works for EAAL quite well (and will for Pheal too). Its one of the things that i think where missing in Yapeal or Ale.

Now you hurt my feelings.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.04 19:42:00 - [18]
 

Edited by: Peter Powers on 04/06/2010 19:43:14
Originally by: Lumy

And that's why Ale allows you to pass it active database connection. Something like this:
$db = mysql_connect(...);
$ale = AleFactory::getEVEOnline(array('cache.db' => $db));

For what it matters, you can define/override any value from config file in same way.

Just saying... Twisted Evil


actually, i didnt find that part in the Docs, probably didnt look deep enough though.. :(
you should get the docs a bit more sorted, but you know that :)

Originally by: Peter Powers
EAAL and Pheal are designed to NOT need changes when CCP adds new pages to the API, thats one of the design goals, and it works for EAAL quite well (and will for Pheal too). Its one of the things that i think where missing in Yapeal or Ale.

Now you hurt my feelings.


ouch, yes, i fail and take back what i said about Ale in this regard. I apologize for unintentionally spreading missinformation. you had the simplexml extending solution which actually works well in this regard. sorry again.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.05 11:03:00 - [19]
 

for those interested in commit notifications, you can follow "King23Framework" on Twitter http://twitter.com/King23Framework

or join the irc channel #king23 at the coldfront network (irc.coldfront.net)
(whenever i do a commit to github to king23 or pheal a bot will join and announce it there)

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2010.06.05 11:26:00 - [20]
 

I think part of the problem you and others sometime miss when looking at Yapeal is where it fits in to the application which I'm sure is because I haven't done as good a job explaining my original design goal as I should have.

I'm sure you're knowledgeable in MVC web design and how it works. Yapeal was made to be part of the Model in that it is helping abstract the data. One of the things I was noticing when I started working on it was there were many people that wanted to make some wonderful new tools/ applications use the APIs but they were getting stuck because they don't know how to work with XML at least in the form CCP used. I understood and found working with it relatively easy and knew that most of them were use to working with databases in 2-3 tier MVC designs so I thought making a library that would take the data from the XML in the APIs and move it into a database they could use and have it be somehow 'Auto-magically' as I called it updated with new data would be a great help. So it was aimed at allowing developers use to making web applications on LAMP/WAMP stacks develop their stuff with minimal knowledge of how the APIs themselves worked.

Other core idea of Yapeal was that the API for the application developer was the database itself. That had the advantage that they could use any language or framework they want for the frontend as long as it could talk to the database.

You also have said you didn't understand why it uses a ini file for some of it configuration. Part of the reason I did choose to use an ini file for the set once and forget stuff like the database user/password and logging settings was every language that I know of either has something build in to the language to work with them or a library/extension or what every they choose to call it to do so. They are also easy for people to understand and make manual changes to if needed as long as you make sure it is well commented Wink All the stuff like adding user/char/corp etc and controlling which API to get data for are managed though tables in the DB and for anyone using PHP I've also added utility classes to help manage them and that are used internally to do so as well now during installation by the installer and for disabling APIs/users/chars/corps during some limited error conditions.

Okay I've took up enough of your thread space talking about my project so I'll wrap this up Very Happy Hopefully you found it interesting and I didn't really plan to pirate it like I have Embarassed

Bai Guang
Caldari
Perkone
Posted - 2010.06.06 05:28:00 - [21]
 

Now i might be a bit late to the party, but having more choices with which library to use is never a bad thing.

I am however, a die hard ALE user as you can do everything in that that you can with this one. Config via app, no need for database, not effected when CCP changes something in the API, etc.

Just my 2 cents Smile

Keep up the good work though.

Kaylana Syi
Minmatar
Coreli Corporation
Naraka.
Posted - 2010.06.18 19:23:00 - [22]
 

Hey Peter. Good work. Good work to Lumy on his project too. I don't suppose you'd look into starting a bitbucket repo for Pheal would you?

I have both but currently really enjoying Mecurial, and it is github's main competitor. It doesn't really need to have all the change tracking, but it would be nice to be able to use the latest repo using Mecurial. I don't want you to do double work but it would be nice to get better accessibility.

Keep up the good work guys.

Peter Powers
FinFleet
Raiden.
Posted - 2010.06.21 08:44:00 - [23]
 

Originally by: Kaylana Syi

I have both but currently really enjoying Mecurial, and it is github's main competitor. It doesn't really need to have all the change tracking, but it would be nice to be able to use the latest repo using Mecurial. I don't want you to do double work but it would be nice to get better accessibility.



Ahoy Kaylana,

first of all sorry for the late answer,
im having alot of RL stuff going on atm.

personally i use git for everything i do in private (and svn at work),
so i dotn really have any knowledge about mecurial,
however, if you want todo that - go ahead and setup a mirror
(let me know if you do), but personally i wont learn to work with
mecurial for this.

If you dont want to use git, all releases are tagged, and therefor can be
downloaded as tgz or zip archive on github, check
http://github.com/ppetermann/pheal/downloads

regards,
PP

Peter Powers
FinFleet
Raiden.
Posted - 2010.07.04 11:17:00 - [24]
 

since a few people have been asking me for more usage examples on pheal,
i have hacked together a small project demonstrating its use,
check out:
http://github.com/ppetermann/king23_pheal_cli
which is basically a set of King23 Tasks to get a hand full of information from the EVE API,
while this example requires King23 (will be installed by using the git submodule stuff),
the lines using Pheal should be understandable and useable without the King23 Framework too.

regards,
PP

Qoi
Exert Force
Posted - 2010.07.27 10:28:00 - [25]
 

Edited by: Qoi on 27/07/2010 10:30:06
new version, fixed bug with caching

on behalf of Peter Powers

Captain Corbulo
FinFleet
IT Alliance
Posted - 2010.08.01 21:24:00 - [26]
 

a bug which caused attributes of an element to be overwritten has been fixed

Kelas Tovat
Posted - 2010.08.07 22:47:00 - [27]
 

Hi, I have been playing around with this library, it's pretty nice. I have one problem though, I have been using it on a dev server I have at home but when it gets really cold here my internet connection gets flaky, this causes a problem when the cache file is out of date and the API server can't be contacted.

I think it would be nice if you added an argument to the cache->load method that allows for forced loading of the cached file. That way if you can't load data from the API you can simply force the loading of expired data from the cache.

I have some sample code below if you would like to work on it more and incorporate it that would be awesome. :D

private function request_xml($scope, $name, $opts)
{
 $opts = array_merge(PhealConfig::getInstance()->additional_request_parameters, $opts);
 if(!$xml = PhealConfig::getInstance()->cache->load($this->userid,$this->key,$scope,$name,$opts))
 {
  $url = PhealConfig::getInstance()->api_base . $scope . '/' . $name . ".xml.aspx";
  $url .= "?userid=" . $this->userid . "&apikey=" . $this->key;
  foreach($opts as $name => $value)
  {
   $url .= "&" . $name . "=" . urlencode($value);
  }
  if($xml = join('', file($url));)
  {
   PhealConfig::getInstance()->cache->save($this->userid,$this->key,$scope,$name,$opts,$xml);
  }
  else
  {
   $xml = PhealConfig::getInstance()->cache->load($this->userid,$this->key,$scope,$name,$opts,TRUE);
  }
 }
 return new PhealResult(new SimpleXMLElement($xml));
}

public function load($userid, $apikey, $scope, $name, $args, $force = FALSE)
{
 $filename = $this->filename($userid, $apikey, $scope, $name, $args);
 if(!file_exists($filename))
  return false;
 $xml = join('', file($filename));
 if($force)
  return $xml
 if($this->validate_cache($xml, $name))
  return $xml;
 return false;
}

You might have to double check that formatting, the forum isn't the best for formatting code.

Peter Powers
FinFleet
Raiden.
Posted - 2010.08.23 08:35:00 - [28]
 

Originally by: Kelas Tovat
Hi, I have been playing around with this library, it's pretty nice. I have one problem though, I have been using it on a dev server I have at home but when it gets really cold here my internet connection gets flaky, this causes a problem when the cache file is out of date and the API server can't be contacted.

I think it would be nice if you added an argument to the cache->load method that allows for forced loading of the cached file. That way if you can't load data from the API you can simply force the loading of expired data from the cache.



first of all, sorry for the late reply,
second - i think the right way of doing that would be implementing a cache class which does that

Peter Powers
FinFleet
Raiden.
Posted - 2010.08.24 22:04:00 - [29]
 

Originally by: Kelas Tovat

I think it would be nice if you added an argument to the cache->load method that allows for forced loading of the cached file. That way if you can't load data from the API you can simply force the loading of expired data from the cache.


ok, i added a new cache variant, which is extending the regular filecache,
and overriding the validation method, this way, if a cache file exists for your request
then it will be used - no matter what - that should be pretty much what you asked for.

usage is simple - instead of
Originally by: "code"
PhealConfig::getInstance()->cache = new PhealFileCache();

you do
Originally by: "code"
PhealConfig::getInstance()->cache = new PhealFileCacheForced();


this change is available in v0.0.5, which i just pushed to github :)

best regards,
PP

Peter Powers
FinFleet
Raiden.
Posted - 2010.10.12 08:25:00 - [30]
 

v0.0.6 is now available,
which is basically a bug fix.

if the api was not reachable after the cache expired pheal would write an
empty cache file and throw an Exception when trying to read that.
Now it should throw a PhealException instead of writing the empty file.

thanks to wengole who found t his bug.


Pages: [1] 2 3

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only