Saltcorn 0.5.3: Block visual programming, multilanguage applications, multi-core

By Tom Nielsen
Published on 

Saltcorn 0.5.3 has been released with three large new features:

You can now build actions using visual programming. By creating a trigger based on the blocks action, you gain access to a drag and drop environment where you can assemble action steps and computations. The available blocks range from basic loops, logic and maths and string operations, to manipulating database tables (query, insert, update, delete tables) making HTTP requests (GET and POST), emitting new events for other triggers to respond to, and sending back instructions with page redirection if the trigger came from a button click.

The blocks are based on the Blockly framework which also powers Scratch and many other no-code platforms. This should make it familiar to many users. When editing a visual program, the corresponding JavaScript code is also shown on the right-hand side. This code can be used in the code-based actions. First constructing your program visually is a great way to learn how to code in JavaScript! For further documentation on the blocks and other aspects of events and actions, see the wiki which has an updated section on this topic

It is now possible to build multilanguage applications. There are two new kinds of text strings that can be translated: firstly, the kind of strings that you supply when you build views, such as static text and button labels. These are now collected and presented for translation under the site structure -> languages settings. Secondly, content that is in the database can also be translated. This is done by adding String fields to the table which are declared to be translations of different String fields. 

Saltcorn can now make use of multiple cores. This leads to a greater throughput and lower response latency on multi-core systems. You can control the number of workers that are spawned using the environment variable SALTCORN_NWORKERS, but if this is not supplied it will default to the number of physical (efficiency, on Apple Silicon) cores in the system. I did a couple of benchmarks on different systems, trying to run with a different number of course and this appears to be optimal.
 


Recent posts