This list is inspired by the classic article by Joel Spolsky entitled The Joel Test 12 Steps to Better Code.
Since Jam.py is a Python Web Framework, we need Python installed on the target Operation System. Get the latest version of Python at https://www.python.org/downloads/ or with your operating system’s package manager.
Python on Windows
If you are just starting with Jam.py and using Windows, you may find Install Python 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:
source ~/Downloads/py3.9/bin/activate pip install jam.py pip install pandas
The above command will install jam.py and pandas packages into
~/Downloads/py3.9/lib/python3.9/site-packages/ directory. 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 Jam.py Export functionality. Since all Jam.py 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.
The Application Builder Export file will not contain the Application database content or structure. Because everything in Jam.py 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:
Please visit posted video Jam.py Application Builder automated testing with pytest and Mocha/Chai, and Simple CRM with jam.py and Selenium IDE in 2.45minutes!.
All necessary tools and libraries for testing should be installed in the same Python virtual environment where Jam.py libraries are.
Continuous Integration (CI)
It is possible to use Continuous Integration as we would with Django.
Sphinx is used as an defacto Python standard. It is very simple to start with using what is already provided with Jam.py.
As a bare minimum, the below files and folders are copied from Jam.py Docs directory into a new directory to create new Documentation:
conf.py index.txt Makefile README.md contents.txt make.bat prepare.py set_scale.py intro: checklist.txt index.txt _static: favicon.ico jquery.js _templates: jamdocs
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
Jam.py is using jam-project.py with no options to create a new project, and server.py to run the project on default port 8080, optionally providing the port number.
Django is using a few different commands, for example manage.py with options, or django-admin with options, etc.
Hence, there are no options to run management commands from the code in Jam.py as in Django.
After running the server.py command, everything is continued in the Web browser, e.g.:
To use a container with Jam.py 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 Jam.py 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 Jam.py 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
Jam.py is providing a lightweight internal Web server for the Development/Testing, just like Django. This means Jam.py is extremely portable. Application can be shipped as is, or so called click-and-run, with just jam folder from Jam.py distribution copied into the Application folder. Of course, Python still needs to be installed locally.
Apache Web Server and
Adapted from Django Docs
Django Docs: If you want to use Jam.py 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. Jam.py will work with any version of Apache that supports mod_wsgi.
If you can’t use mod_wsgi for some reason, fear not: Jam.py supports many other deployment options. It works very well with nginx. Additionally, Jam.py 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 Jam.py for more information.
Choosing the Database
Similar to Django, Jam.py attempts to support as many features as possible for supported databases. However, not all database backends are alike, and Jam.py design decisions were made on which features to support.
As contrary to Django, Jam.py has no models, classes, subclasses and attributes. Since Jam.py 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
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, you’ll need to make sure your Python database bindings are installed.
Using MySQL on Windows is supported, please visit MySQL deployment on Windows.
Even though Jam.py 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 are specific to the database vendor and Jam.py 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.
The database views are specific to the vendor too, and Jam.py does not support it for now. The same applies as for database triggers.
Indexes creation/deletion is supported with Jam.py. 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, Jam.py does not import indexes information. This might lead into lost indexes if moving the Application to different environment by Jam.py Export/Import utility.
The database sequences are supported and Jam.py 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.