WSManage progress

We’ll, I’m making some progress getting rid of all the xajax stuff in WSManage. I’ve also changed the way the processing script is launched. I used to launch it directly from an ajax call, but the problem was tracking the script. Since everything was happening asynchronously, there is no way php can keep a file handle open on the process_queue script. If the script crashes, it’s hard to detect it properly.

To combat this, I’ve written a very very simple script that should never crash called process_queue_init. It’s only job is to start process_queue, grab the exit code when it exits, and set processing to false when it’s done. I’m using exec() to call process_queue, so execution of process_queue_init will just hang until process_queue exits. This way I can tell exactly when the script ended (without having to try to look through ps output) and whether or not it crashed. I have defined my own exit codes for different problems, and php always exits with code 255 if there is a scripting error.


Converting from xajax + jQuery to just jQuery

I’ve been working on the web based version of WSManage for a couple of weeks now, getting the mess I have straightened out.  WSManage is the console that my dad uses to administer the video/audio clips on  When I originally coded it, I used xajax to communicate with the server side and manipulated the gui with pure javascript.  Then, I found how easy it was to work with the gui if I used jQuery instead of coding all the javascript by hand.  This was nice, besides the fact that I had a lot of places where I’d have a button click handler calling xajax, which wrote jQuery code to manipulate the gui from the server-side.  Not cool.

So, I’ve been going back and replacing all the xajax server code with php that just prints the return data, and using jQuery’s ajax functions to make the calls to the server.  This way I can handle the data on the server, send back anything I need to the javascript, and handle gui manipulation ONLY in the javascript.  The separation of data/model from the view is much nicer and much easier to maintain.  Not only is the code less cluttered, but there are fewer lines of code in general and fewer places where code jumps back and forth between server-side code and javascript.

When this is finished, it would make it easier to make gui changes as well.  None of the server code will rely on any specific presentation.