Development Checklist

This list is inspired by the classic article by Joel Spolsky entitled The Joel Test 12 Steps to Better Code.

Built in Code Editor

For the JS and Python code, has a built in Ace Code Editor. The best is to familiarise with the editor shortcuts from here:

The most used shortcuts:












Toggle comment



Toggle block comment

It is absolutely possible to extend the ACE editor for AutoCompletition or Themes.

Python version

Since is a JavaScript and Python Web Framework, we need Python installed on the target Operation System. Get the latest version of Python at or with your operating system's package manager.

Python on Windows

If you are just starting with and using Windows, you may find How to install on Windows useful.

Using Python Virtual Environments

Virtual environment is strongly encouraged for any Python development. When compiling Python from source, we would normally install all binaries in some folder, so we can use different Python versions for different projects.

This is particularly true with the Apache Web server and mod_wsgi module, when the module is compiled against specific Python version, and loaded as per Apache procedure.

Standard Python library is used to create a virtual environment. After creation, the new environment must be “sourced”, and all packages installed with pip:

$ python3 -m venv project-name

$ source project-name/bin/activate

$ pip install

If installing from source, for example downloaded zip archive from Github, unzip the archive, navigate to the folder and install with pip:

$ pip install .

We can have as many virtual environments as needed.


It is advisable to have Production and Development environments.

Using the Source Control

Using Source Control is encouraged with Export functionality. Since all code is stored in the internal database, it is possible to only Source Control the admin.sqlite database, or it’s content by exporting the tables.

However, for the static files, for example JavaScript libraries, or CSS files, the best approach would be using Export which fetches all objects into one compressed file. It is possible to create an automated Export, for example:

Automated config backup

The Application Builder Export file will not contain the Application database content or structure. Because everything in is developed inside the Application Builder, it is not possible to create different branch for the Application only. This is the main difference comparing to Django.

The utility to completely track the application changes, even the database structure, is here:

Storing Application in GitLab

Unit Testing version higher then v5 is using pytest and Chai/Mocha. It is also possible to use Selenium IDE for the browser.

Please visit posted video Application Builder automated testing with pytest and Mocha/Chai, and Simple CRM with and Selenium IDE in 2.45minutes!.

All necessary tools and libraries for testing should be installed in the same Python virtual environment where libraries are.

Continuous Integration (CI)

It is possible to use Continuous Integration as we would with Django.

Generating Documentation

Sphinx is used as an defacto Python standard. It is very simple to start with using what is already provided with

As a bare minimum, the below files and folders are copied from Docs directory into a new directory to create new Documentation:       index.txt  Makefile
contents.txt  make.bat

checklist.txt  index.txt

favicon.ico  jquery.js


Modify all files for your preference and build the documentation. For example, the below command will build one single html file:

$  make singlehtml

For more professional look, the latexpdf option might be used.

$  make latexpdf


Latex libraries are quite large and the installation is on the OS level. Sphinx can be installed inside Python virtual environment.

Limited introduction to the tool is using with no options to create a new project, and to run the project on default port 8080, optionally providing the port number.

Django is using a few different commands, for example with options, or django-admin with options, etc.

Hence, there are no options to run management commands from the code in as in Django.

After running the command, everything is continued in the Web browser, e.g.:


Since is mostly JavaScript based, most of Debugging work is done via browser debug console. It is possible to debug the Server side Python code with print command as usual.


It is strongly suggested not to run production Applications with the command only. Instead, a proper Web server should be configured. Most of the Web server speed benefits are from compressed content sent from the Web server to the User browser, which is particularly true for CSS and JavaScript files. In addition, has a special static folder where all images files and documents are remaining, and this files are served by the Web server bypassing the Apache mod_wsgi or similar Python interface for other Web servers. Serving the static might be possible with a separate Web server, similar to Django tactics. has no utility as collectstatic Django command, and rsync might be used in this scenario.


To use a container with is easy. However, the decision has to be made if the Application will use Reports based on LibreOffice (LO), since packaging complete LO might be prohibitive due to a container size. If not using LO, but plain CSV export or other mechanisms for reporting, the container size is small and fast to build. Special consideration needs to be made about hosting the Application database and separate admin.sqlite and langs.sqlite internal database.

Please refer to more info in here: Use external database for admin e langs

It is also possible to run Application as an Azure Web Application, or AWS Functions, hence server less.

Please refer to more info in here: Azure Deployment

Choosing the Web Server is providing a lightweight internal Web server for the Development/Testing, just like Django. This means is extremely portable. Application can be shipped as is, or so called click-and-run, with just jam folder from distribution copied into the Application folder. Of course, Python still needs to be installed locally.

Apache Web Server and mod_wsgi

Adapted from Django Docs

Django Docs: If you want to use on a production site, use Apache with mod_wsgi. mod_wsgi operates in one of two modes: embedded mode or daemon mode. In embedded mode, mod_wsgi is similar to mod_perl – it embeds Python within Apache and loads Python code into memory when the server starts. Code stays in memory throughout the life of an Apache process, which leads to significant performance gains over other server arrangements. In daemon mode, mod_wsgi spawns an independent daemon process that handles requests. The daemon process can run as a different user then the web server, possibly leading to improved security. The daemon process can be restarted without restarting the entire Apache web server, possibly making refreshing your codebase more seamless. Consult the mod_wsgi documentation to determine which mode is right for your setup. Make sure you have Apache installed with the mod_wsgi module activated. will work with any version of Apache that supports mod_wsgi.

If you can’t use mod_wsgi for some reason, fear not: supports many other deployment options. It works very well with nginx. Additionally, follows the WSGI spec (PEP 3333), which allows it to run on a variety of server platforms.

mod_wsgi is tightly coupled with Python and quite often shipped as the default Python version installed on the Operation System. When developing Application in an Python Virtual Environment, for example on the Developer’s computer, it is possible that Python version does not match the mod_wsgi version activated in Apache due to Python mismatch. To solve any problems with Python differences, it is suggested to install mod_wsgi for Apache from the Virtual Environment which matches the Development/Test environment.

Please visit Apache on Windows mailgroup thread for using Apache with Windows.

IIS Web Server

Using IIS Web with FastCGI is supported. Please visit JamPy deployment on Microsoft IIS for more information.


Using CPanel is supported. Please visit Success with cPanel v82.0.12 and for more information.

Choosing the Database

Similar to Django, attempts to support as many features as possible for supported databases. However, not all database backends are alike, and design decisions were made on which features to support.

As contrary to Django, has no models, classes, subclasses and attributes. Since is exclusively using Application Builder, there is no code to develop model to database table relationship, or table fields specified as class attributes.

Adapted from Django Docs

Django Docs: supports many different database servers and is officially supported with PostgreSQL, MariaDB, MySQL, MSSQL, Oracle, Firebird, SQLite and SQLite with SQLCipher.

If you are developing a small project or something you don’t plan to deploy in a production environment, SQLite is generally the best option as it doesn’t require running a separate server. However, SQLite has many differences from other databases, so if you are working on something substantial, it’s recommended to develop with the same database that you plan on using in production.

In addition to a database backend, we need to make sure the Python database bindings are installed.

  • If using PostgreSQL, the psycopg2 package is needed.

  • If using MySQL or MariaDB, the MySQLdb for Python 2.x or mysqlclient for Python 3.x is needed, as well as database development files.

  • If using MSSQL, the pymssql is needed.

  • If using Oracle, the cx_Oracle is needed.

  • If using SQLCipher, sqlcipher3-binary is needed for Linux. There is a standalone DLL for Windows available.

Using MySQL on Windows is supported, please visit MySQL deployment on Windows.

Even though supports all databases from the above, there is no guarantee that some specific and/or propriety database functionality is supported. Here we name a few.

Database triggers

Database triggers are specific to the database vendor and does not support creation of triggers within the Application Builder. It is absolutely possible to use triggers, however, when moving the Application into the ie. Production, the Application Export file will not contain any information about the triggers and they need to be recreated manually.

Database views

The database views are specific to the vendor too, and does not support it for now. That is, it does not support a View creation or modification. It does support the View access though. If the View is needed, we can create an table with the same View name and needed fields, providing the Builder Project Database option is set to “DB manual mode” when doing it.

Same as for database triggers, the Application Export file will not contain any information about the Views.

Very similar to Database Views are Virtual Tables. More about the Virtual Table is covered in Northwind Traders.

Database indexes

Indexes creation/deletion is supported with The indexes information is stored in the Application Export file if the indexes were created by Application Builder interface. Not all vendor specific index functionality is supported, ie. Oracle function based index, etc. The Primary Key creation will result in creating an index. When working with legacy databases, meaning the tables were Imported and not created by the Application Builder, does not import indexes information. This might lead into lost indexes if moving the Application to different environment by Export/Import utility.

Database sequences

The database sequences are supported and is providing an interface to use the sequence generator. Not all sequence generators can be used as this is specific to the database vendor. The Export file does not store the sequence definition, just the name of the sequence used.