jQuery Javascript Library has Problems?
I was trying to load the jQuery Javascript Library docs today, and recieved this ridiculously amusing response from the server.
Now, I’m not a marketing wiz or anything… but I do believe, that’s just not a good error message.
I’m going to continue enjoying my usage of the jQuery Javascript Library, even though it’s developers think “it has a problem”.
Eve Online API and PHP
A buddy of mine just recently started playing Eve Online and asked me if I could help him out by creating a small application that could help him keep track of his corporations transactions and members. He directed me to the Eve Online API Documentation and explained what he wanted to do.
I took one quick look at it, saw that they had a Python sample -- reviewed it, even tried it myself in a python shell real quick. Due to the python sample code, I almost said "Oh hey, a perfect use for Google App Engine. But then decided not to go that route, as I was hoping to host the application myself and have a bit more control over the data and the amount of data I could work with at a time. I toyed with the idea of writing it in either .NET or PHP and went with PHP. I haven't written anything in PHP for a few weeks, and I'm all over the .NET code at my day job ... so, PHP was a 'lets make things more complicated then they have to be' decision.
As such, to develop this application, I am creating what I call the 'EveAPI Class' for PHP -- which is basically just a class that has all the necessary functions and properties to retrieve any and all information accessible through the Eve Online API.
A quick example of usage is this:
-
$eve = EveAPI::Create($userID, $apiKey, $characterId);
-
$object = $eve->getCorpWalletData();
Yep, it really is that simple -- the 'toHtmlTable' is a helper function that belongs to the 'EveResult' class. The 'EveResult' class simply contains the following:
-
class EveResult {
-
var $name; // the name of the result set
-
var $count; // the number of rows in $rows
-
var $time; // the currentTime node
-
var $cachedUntil; // the cachedUntil node
-
var $api_version; // the api version
-
var $raw_response; // the actual XML response from the server
-
-
var $timeOffset; // the time offset between currentTime and time()
-
var $localExpiration; // timeOffset added to cachedUntil
-
-
-
function toHtmlTable() { /* code snipped */ }
-
}
All the functions of the EveAPI class implement a session based server-side caching, and retrieve 'cachedUntil' results from this until the 'cachedUntil' time has passed.
I haven't written much code yet to actually do what my buddy asked for, but so far, I've got a fully functional 'EveAPI Class' in PHP5 (Not sure if it's PHP4 compatible?).
I intend to release the 'EveAPI Class' to the general public once it's been tested a bit more and I've added a couple more things to it -- right now, all the functions are targetted toward corporation data only ('/corp/' page requests). I intend to add the '/char/' page requests, shortly.
jQuery 1.0.4 and jQuery Growl
Per request, I attempted to back-port jQuery Growl to support jQuery 1.0.4 -- which is the default version of jQuery shipped with Drupal 5.x (5.4 was the target drupal version). Unfortunately, after digging around quite a bit, I realized that jQuery 1.0.4 had so many bugs in it that it was impossible for 'me' to back-port my Growl implementation without rewriting it from the ground up and essentially relearning jQuery all over again (ignoring everything I know of the 1.2.x releases, and learning 'old school' jQuery methods).
This turned out to be so problematic, that I eventually gave up after a few hours. Some of the things I noticed in jQuery 1.0.4 was the lack of variable checking, ensuring that the variable had a value before attempting to access items within it. Others were the lack of support for certain CSS properties, etc.
I did, at one point, get a copy of jQuery Growl working with 1.0.4 locally but once I deployed it to my server as version 1.0.0-b2 and tested it on my remote server with the 'fortune.php' implementation, it failed to work properly and I was unable to determine the cause of the problem.
So, with that said ... I'm so glad that jQuery has matured to the point that it is at now and I hope that it continues to get better and better. I don't think I would be so interested in jQuery if I had started using it prior to the 1.2.x releases -- buggy frameworks tend to make me walk away, run away in fear in some cases.