OSIMS

I’m building OSIMS as a series of Xaraya modules enhanced with ExtJS.  Xaraya does a great job at returning whole webpages of information, but that may be more than I need in many cases.

How Xaraya Builds Pages

Web page requests come in through the Xaraya core and are routed to the appropriate module and function.  They are routed based on three variables: module, type, and func .  The type is generally used to define if these are admin (data manipulating) functions or user (data viewing) functions.  Effectively, it tells the core in which folder of the module it can find the function.  Requests are sent through display functions which in turn make requests to the API functions that actually interact with the database.  The results are bundled up and applied to the appropriate template which results in the webpage that is displayed.

Using ExtJS, OSIMS is going to be a heavily Asynchronous Javascript And XML (AJAX) program.  When creating AJAX type programs, the web browser sends dozens of requests for small pieces of data.  Where a non-AJAX program might allow a user to choose a School District from a select box and then reload the entire web page to get the appropriate schools in another select box, an AJAX program would just send a request for the schools in the background and quietly update the list.  The responses from the server shouldn’t be whole webpages which then need to be boiled down to discover the relevant data.  Such an approach adds a lot of overhead and complexity to both sides of the equation as well as drastically increasing the bandwidth requirements.

My first attempt to reduce the amount of data coming back from the server was to create a Xaraya theme called “ajax” which did nothing more than wrap the module’s response in <xml></xml> tags.  By having my javascript send its requests with theme=ajax as a variable, I would get back just the basic responses from the module without any menus, headers, footers, or styling.

This worked pretty well, but what I found was that I was creating little mini-functions that did nothing more than pull data from the database APIs and then turn that data into an XML structure to be sent out.  The whole thing was kind of messy requiring me to create functions and templates for every little thing that could possibly be requested.  What I found is that I really just wanted to take the data straight from the database API and send it to the javascript.

AJAX (AJAJSON?)

At the same time I was questioning the need for XML and finding that there was perhaps a better transfer method.

AJAX stands for Asynchronous Javascript And XML, but the ExtJS authors prefer to use something called JSON or JavaScript Object Notation to transfer data from the server to the javascript code.  With JSON, the server sends back valid javascript code which can be quickly interpreted and used by the javascript engine.  Not only does this reduce the parsing overhead, but it also cuts down on the data size since javascript notion is more concise.  A JSON response for two students might look like this:

{students:[{'firstname':'Brian','lastname':'Bain','birthdate':'1997-07-29'},{'firstname':'John','lastname':'Doe','birthdate':'1997-11-07'}]}

where the same XML might look like this:

<students><student><firstname>Brian</firstname><lastname>Bain</lastname><birthdate>1997-07-29</birthdate></student><student><firstname>John</firstname><lastname>Doe</lastname><birthdate>1997-11-07</birthdate></student></students>

Even with just two records it’s easy to see the JSON response is much shorter.  Imagine pulling data on thousands of students.

The decision to switch from XML to JSON became even clearer when one release of ExtJS included new functionality for writing to the database in JSON that wasn’t available  in XML.  It may have been an oversight in a single release, but it was enough to persuade me to make the change.

Specialized JSON Functions in Xaraya

Instead of returning XML through a specialized theme and creating dozens of functions and templates, I’m going to to create javascript specific functions that hook straight into the Xaraya API and return JSON results.  My javascript will now send requests to the “json” type rather than “user” or “admin” and those functions will take the results straight from the API and encode them as JSON.  I’ve created a helper function within the ExtJS module just in case PHP isn’t loaded with JSON support.

A brief example of this in action might look like this:

function students_json_read(){
  xarVarFetch('id','id::',$args['id'],0,XARVAR_NOT_REQUIRED);
  $result['items'] = array_values(xarModAPIFunc('students','user','get',$args));
  if($result['items']){
    $result['success'] = true;
    $out = xarModAPIFunc('extjs','user','encode',$result);
  }else{
    $result['success'] = false;
  }
  echo $out;
  exit();
}

The OSIMS Store in ExtJS

Since nearly every module that I’m going to build will have the same sort of functions (create, read, update, delete), it makes sense to build common components that can be re-used.  In ExtJS, I’ve created my own datastore by extending the provided JsonStore with some predefined settings.  By doing this, I only need to define the specific Xaraya module that I want to interact with, and which fields should be expected back and I’ve given ExtJS everything it needs to know to read and modify data for that module.  It knows to send the requests through my json type to the module  and which functions to hit.  Now setting up a datastore that can interact with my student data is as simple as

 {xtype:'osims_store',module:'students',fields:['id','firstname','lastname','birthdate']}

Filed under:
Uncategorized by Brian Bain