Here are some of the principles that guided the design and development of Saltcorn:
we embrace open source and free software as a development and a community model. Every other principle and design decision are subordinate to the principle of growing Saltcorn as an open and free community. We put no barriers to how people and companies can use the Saltcorn code base and software and facilitate self-hosting and alternative commercial hosting options by releasing the multi-tenancy hosting capacity. Likewise,
A single program handles the front end data display for end users, the admin interface for building sites, back-end data management, and server for pages and files.. The actual data is stored in a relational database such as PostgreSQL. In this respect Saltcorn follows the model of WordPress and other classical CMS systems. In fact, we often think of Saltcorn as a CMS for structured data.
Most of the layout decisions in Saltcorn are made by a theme which can be installed as a plug-in. That way, Saltcorn applications can achieve a diverse range of look and feel, and one layout can be swapped for another without extensive work from the application builder.
The relational data model is well understood, well tested and capable of formalising many different application data models in a clean and simple structure. Relational databases are extremely robust and scalable, and their use is well documented.
If a facility is moved from the core Saltcorn process to a plug-in, that means that it can be unfermented differently in a different plug-in if necessary, leading to a more flexible overall solution space.
In general, in software engineering we favour producing value for the user over maintaining a clean code base. If a bit of messiness creeps into the code base, it is not the end of the world as you can always clean it up later if you have provided value to the end user. (If you don’t provide value to users, it doesn’t matter if the code base is clean or messy.) If on the other hand your primary data store becomes messy, that can be a devastating situation that it can be difficult to recover from. We always maintain a clean data model. A database for a Saltcorn application should look as if it has been designed by a competent data modeller. This makes it possible to transition from Saltcorn to a code application.
We use the good, simple parts of object-oriented and functional programming. This means no inheritance or only one inheritance layer but do use objects for mutable state as necessary. Write concrete rather than abstract code. Use anonymous functions and higher order functions generously, avoid more advanced patterns as they quickly lead to unreadable code.
Use design by contract to provide test-time type checks and checks for properties that are more difficult to predicate in type systems. We wrote our own design by contract library for Saltcorn. Contract checks are enabled in production and will crash the application on a contract violation. Let it crash, loudly, so you know what to fix.