Global Overview

PHP <=> XML <=> Ajax

AjaXplorer is based on the PHP scripting language for the server-side, and a fully oriented Ajax GUI. This interface is served by the file index.php which has this only function. Once initialized, every other query will go through the content.php « service » : it is based on the standard php mechanism : queries parameters are sent via GET or POST variables to the script, and it will answer with various Content-Type outputs, depending on the input queries. In AjaXplorer, except for the downloads that will output « force-download » headers and binary data, script output are mostly formatted in XML.

Even if deeply discussed nowadays in the IT, XML is clearly suiting very good for the encapsulation of data and metadata used by the application. DOM and XPath are heavily used on both server and client side to navigate through the XML data, so it’s not really an option to communicate through another mechanism like JSON. Maybe some very specific performance needs could lead to switching some queries to this format, but it’s not the case now.

The basic API for the content.php service is the only mandatory get_action parameter. This parameter can be seen as the target service the query is adressing. The following parameters will depend on this get_action value. This « actions » are in fact defined in XML files that will create the bunch of features the application offers. See the Plugins Architecture paragraph for more details.

Developer Tools

Working on Ajax GUI needs a different approach than good old HTML. The complex structure of the JavaScript GUI in itself, and the dynamic building of DOM elements make it even harder to debug when you have display problems, and for the communication with the server, the principle being that all queries are done by XmlHttpRequest and not by a reloading of the page, by default they are « hidden » to your sight.

To solve these problems, the best tool ever : the Firebug extension for Firefox. It will allow you to scan the DOM structure in real time, monitor the XHR queries, debug the JavaScript, etc. But be also aware that what you develop will be executed on many different browsers : Firefox yes, but also Webkit (chrome/safari), Internet Explorer, Opera, etc… Always test your changes on all browser!! To help you with this task, most of the recent versions of these one also offer « firebug-like » developer tools (but not as good as firebug in my opinion).

JavaScript Compilation?

When manipulation huge Javascript frameworks, it’s now a common task to apply a transformation to the javascript source to make it smaller. This « compilation », in fact a succession of obfuscation and minification, leads to a drastic gain in download and in performance for the users. The same kind of transformation is applied to Cascading StyleSheets to make them smaller. The only backdraft of this is that when you are developping, you’ll have to compile your changes in both the JavaScript and the CSS, to be able to see them appear in the GUI. In fact, the configuration option AJXP_JS_DEBUG in the conf.php file is here for that: when set to true, the GUI no more calls the compiled version of the files, but each file separately. Thus you can debug much more easily, and once you’re finished, you compile and refresh your application.

To compile, still in « debug » mode, call /path/to/ajaxplorer/index.php?compile=true. Then you can either switch back the AJXP_JS_DEBUG to false, or if you are in a developement cycle and don’t wan’t to edit the conf.php file each time, you can call /path/to/ajaxplorer/index.php?skipDebug=true.

You must be aware that this « compilation » transforms the JavaScript code and among other, removes all line breaks. This means that your JavaScript syntax must be « perfect » to avoid seeing errors appear in your compiled version that are not detected in the original version. For example, a forgotten semi-column at the end of a line may pass through in source mode, as the line-break is interpreted as a « ; » by the Javascript interpreters, but this will make an error in compiled mode. And it’s much more hard to debug in compile mode, even with some tool like Firebug (see below), because the JS file seen by the browser is a huge one-line file not human-readable at all…

Data Structure

The AJXP_Node is now the basic container for all data. It is loaded with a simple path from the root of the current repository, and goes through all metadata providers that enrich its data. The nice part is that for example even access.fs is seen as a metadata provider : the filename, filesize, etc, are metadata, in the same sense as a user-entered serial metadata.

To implement this model, there are two basic hooks described below. Plugins that register these hook in the manifest.xml must implement specific methods in their php class implementation.

node.info : enrich a node with any number of metadata
node.change : perform necessary actions upon creation/deletion/move/copy of a given node. For example on deletion, the action taken can be « remove from indexation », « remove associated serialized metadata », etc..
Below is a sample of how an « AJXP_Node » can be created, filled with metadata, then printed out as XML for the client.

Next : Plugins Architecture

Updated over 8 years ago by Charles du Jeu Admin