Frequently asked questions¶
Python 2 vs. Python 3¶
Python 3 is technically superior to Python 2: built-in TSL (HTTPS), hundreds of paper cuts fixed in standard library, nested exceptions, asynchronous input/output and optional type hinting.
Python 3 has better library supports for maintained projects.
All common Linux distributions have switched to Python 3 by default.
There is no point of starting a new project in Python 2 anymore. Websauna aims to support fresh projects started after its initial release.
Template engine¶
You are free to use your favorite template engine. Plug in your template engine in websauna.system.Initializer.configure_templates.
The default templates are written in Jinja 2. Pyramid supports multiple template engines, so you do not need to rewrite these templates. The engines can be mixed and matched to a certain degree. In fact the underlying form widget library Deform uses Chameleon templates internally.
Form framework¶
Pyramid project has multiple supported form frameworks (Deform, WTForms, ToscaWidgets. You can easily use your favorite form framework for public facing forms.
The default CRUD, administrative interface and form autogeneration are based on Deform. At the time of writing Websauna, Deform was technically superior choice of available form frameworks. However, Websauna CRUD is abstracted. If you want to use your own form framework for CRUD you can plug it in at websauna.system.crud.views.FormView.create_form(). Just create your own FormView based view set for another form framework.
Organizing code¶
With Websauna, the developer is in the driver’s seat.
Websauna comes with a default project Scaffolds which gives a suggestive project layout. This project layout, by all means, is not definitive. If you are a novice it is suggested you stick with this. If you have experience you can bring your own best practices of organizing Python files and page templates.
There are no assumptions about file layout: You are free to organize files any way you wish.
There are zero global variables
All behavior can be changed during run time (request object available) or configuration time (configuration object available)
You are in control of an application WSGI entry point
Entry points usually executes
websauna.system.Initializerwhich sets up default engine parameters (database connection, where to find template folders, wired models).You can override default behavior with subclasses
websauna.system.Initializer. Just override or remove each method you do not wish to use. Seewebsauna.system.Initializer.run()source code of initialization order and methods.
Amount of dependencies¶
Websauna has many dependencies at the moment. Expect the number of dependencies going down, as they are being cleaned up and unnecessary functionality being culled off.
For example, some of functionality of minor dependencies can be moved to Websauna core. Some of them can be made optional (IPython).
UUIDs or running counter ids¶
For security reasons it is suggested to use non-guessable ids (UUIDs). Websauna embraces security best practices and thus suggests you to stick with this. You can still use old fashioned running counter ids.
CRUD supports both behaviors out of the box (see websauna.system.crud.urlmapper).
So many things¶
Websauna integrates existing, well known libraries and provides polished solution based on them. The amount of code in Websauna itself is kept minimal; patches are sent to upstream libraries. New features are planned to rolled out as a separate libraries for maximum reusability even though they would start their life inside Websauna core.
The minimal viable features set for Websauna is a website where you can login and sign up out of the box, have easy administrative access to data, all this in security critical environment.