Copyright © 2011-2014 airxc.com, airxcell.com
AirXCell intents to provide the user with a GUI (Graphical User Interface) which she can use to perform most common tasks one usually uses a spreadsheet application or a mathematical computation environment for. It attempts to get the best of both worlds within a single, coherent and unified application.
AirXCell is built on top of R (The R Project for Statistical Computing). R is a free and open source advanced mathematical computing environment. Initially, R was oriented towards solving or computing statistical problems. Nowadays R is rather a pretty complete mathematical computing environment and can be used for a very broad range of mathematical applications. In addition, R is free, robust and scalable, making it the first choice for the AirXCell calculation engine.
AirXcell is not only a spreadsheet or an R GUI, it provides the user with an R Console (4.2.4), an R Code Editor (6), a Data Frame Viewer and Editor (8), a Chart Wizard (7) or various Dynamic Forms (2.1.5) that can be easily created by the site administrator to build any kind of User Interface on top of the R calculation engine.
In fact, pretty much everything in AirXCell except the global UI (User Interface) canvas with the Console, the Menu Bar, etc. is a module (2.1.1).
AirXCell is not a spreadsheet software or an R Code Editor per se. AirXCell is rather a framework for building online Web application using the R calculation engine. Various modules are written on top of this framework to provide the user with utilities of all kind. The framework behind AirXCell supports the module execution platform with GUI (Graphical User Interface) components and the various abstractions aimed at helping the modules use the R calculation engine as well as specific behaviours they may well require.
As of version 0.5.10-SNAPSHOT, there are four modules implemented :
In future versions, there will likely be several additional modules.
Each module really implements in a way a complete new application on top of the AirXCell framework. For instance the Code Editor (6) module has only little to do with the Calculation Sheet (5) module, even though a script executed from the Code Editor has full access to the underlying R matrix representing a Calculation Sheet.
This separation of concerns is not enforced though. For instance the Chart Wizard (7) is tightly coupled to the Calculation Sheet (5) since its only goal is to provide the user with assistance in creating charts and graphs from values in a Calculation Sheet.
In addition to modules, AirXCell provides the interesting concepts of dynamic forms (2.1.5). Dynamic forms are much more limited in terms of User Interface or possibilities than modules since they are edited from within the application. But the fact that they can be developed completely dynamically, i.e. without any change on the AirXCell codebase is a strong advantage considering that a change can be implemented and put at disposal of the user within seconds. The runtime support for dynamic forms is implemented by a specific module though.
A module is an application, almost a complete software on its own, not a particular usage of that application. As an example, whenever the user creates a new Calculation Sheet (5) in her Workspace (2.1.4), we say that she instantiated a new Calculation Sheet module.
Modules instantiated in a user workspace, kind of new sheets added on an usual spreadsheet software, are called module instances. A user can create or open as many module instances in her workspace as required.
AirXCell supports a wide range of keyboard shortcuts for various usages. Every feature available from the menu or a toolbar displays the corresponding keyboard shortcut as a hint whenever the user leaves the mouse over it for a moment.
In addition to these features, most common shortcuts such as Copy / Paste with Ctrl + C / Ctrl + V or switching the currently displayed tab using Ctrl + Shift + PG_UP / PG_DOWN are supported.
Graphical facilities in R :
From http://cran.r-project.org/doc/manuals/R-intro.html#Graphics :
Graphical facilities form an important and extremely versatile set of components of the R environment. With R, it is possible to create almost every posible kind of graphics or event to build entirely new types of graphic.
The graphical facilities can be used in both interactive and batch modes, but in most cases, interactive use is more productive. Interactive use is also easy because at startup time R initiates a graphics device driver which opens a special graphics window for the display of interactive graphics.
Chartting commands are divided into three basic groups:
In addition, R maintains a list of graphical parameters which can be manipulated to customize your charts.
Graphical facilities in AirXCell :
AirXCell fully supports each and every high-level and low-level chartting functions. It provides the user with a virtual graphic device acting as an interceptor on charts generated from the underlying R environment. The intercepted graphic is sent towards the user's browser and displayed as an image inside of the AirXCell application. This feature is called Chart Interception.
Interactive graphics functions are not supported however. See AirXCell limitations - interactive charts. (2.3)
Chart interception occurs transparently without any specific action from the user. Whenever a chart is generated within the R environment, whatever the source, it is intercepted and displayed to the user. The source from which the chart is generated doesn't matter, it can be the R Console (4.2.4), a Chart Module (7) instance or a Dynamic Form (2.1.5) instance
Just as the R environment, a unit of work in AirXCell, i.e. the collection of all module instances (2.1.1.1) belonging to the same task or opened in the AirXCell application at the same time is called a Workspace. A Workspace in AirXCell is the same as a Workbook for instance in other popular softwares.
The term Workspace comes from the R environment where it designates an R session in the R environment. Workspaces in AirXCell can be stored on the user local computer or online on the remote R server (4.4.1).
AirXCell Modules (2.1.1) are interesting since they enable the AirXCell developers to provide and implement various kind of different applications on top of the AirXCell framework. Yet every new module or even only every single change applied on a module requires the AirXCell administrator to deploy a brand new version of AirXCell; hence the need for something else: the Dynamic Forms.
The Dynamic Form Subsystem is a mean offered to administrators, maintainers or webmasters of an AirXCell deployment to create brand new custom and specific applications using the R calculation engine, the AirXCell server backend and the AirXCell GUI. The idea is to implement new HTML forms and R programs within AirXCell without the need to change anything on the AirXCell codebase nor to redeploy or reinstall the software.
Dynamic forms consist of an HTML formular, the one shown to the user, and an R script that is tightly bound to this formular. The AirXCell Dynamic Form Subsystem intercepts the values set by the user and the actions performed on the HTML form and injects them in the R script before it is executed within the R environment.
This way, it becomes easy and almost straightforward to build any kind of Web Graphical User Interface on top of any R program. A dynamic form, just as a real application, needs to be executed by the user. The execution is triggered either by pushing a Submit button placed on the form itself, or using the Execute button on the dynamic form module toolbar.
A few dynamic forms are already implemented in the current version of AirXCell:
The features available from the toolbar are as follows:
Show Dynamic Formular : show the dynamic formular.
Show Results : show the the results returned by the server upong form execution.
Run : run the formular and get the results.
AirXCell is built on top of R. Each session a user opens on AirXCell is bound to a virtual R session as well. That R session has a few limitations though. For instance, it is not possible to the end user to install any new package.
The set of R packages available to end users is listed below.One should note though that
these packages need to be loaded by the user before their functions become available in the
workspace.
A package is loaded within R using the plain old R command : require('package_name')
.
Table 2.1. List of available R packages within AirXCell
|
|
AirXCell limitations as of version 0.5.10-SNAPSHOT are as follows :
Static plots are supported in the form of a PNG device. All the usual limitations of the R PNG image device apply to AirXCell. In addition, the user should not try one of R's mechamisms to change the plotting device since they are not supported by AirXCell so far. (Any attempt to do so would lead to unpredictable results and is verly likely to corrupt the AirXCell workspace.)
Interactive charting functions are not supported. AirXCell does not implement so far a fully functional virtual interactive graphic device on the R backend side. As such, it is yet not possible to forward user actions performed on the graphic within the GUI to the R side.
When working in an R environment, one often uses extensively the file upload feature and data loaded from files on the R side.
A problem arises here with AirXCell since file upload is not yet supported. One can still use the file import feature from an R Code Editor (6) or from simple R commands executed in the R Console (4.2.4) but as it is not possible (yet as of version 0.5.10-SNAPSHOT) to upload any file on the remote R environment, the ability to load data from files is pretty useless.
There is however a workaround to this limitation as described in Section 6.2, “Loading files in the R environment” since it is possible to upload a CSV file on the spreadsheet.
Whenever the user executes an endless script - i.e. for instance an infinite loop from within the R Console (4.2.4) or the R Code Editor (6), there is no chance to recover the workspace since the AirXCell backend will never give hand back to the AirXCell User Interface
In this case, the workspace is killed on the AirXCell backend after 5 minutes of continuouus execution. At that moment the user received a failure notification and can only close her workspace and restart from scratch.
We can therefor not stress enough how much it is important when developing R scripts with AirXCell to avoid infinite loops and endless scripts.