What changed in version 3.2¶
This release extends Reahl with (experimental) Bootstrap support.
Going forward (Reahl 4.0 onwards) we will base all our Widgets and styling on the Bootstrap web frontend library with the aim of sporting a better look and better layout tools.
This release is a transitional release: it has Bootstrap based Widgets and Layouts added side-by-side to what already exists. However, since Bootstrap 4 was still in alpha at the time of this release, this support is labelled as experimental and it is not enabled by default.
The addition of Bootstrap-based
Widgets is the major change
prompting this release. How it works, how its different and how you can
enable it are all discussed in the tutorial and won’t be repeated here.
Configuration and DANGEROUS defaults¶
Some configuration settings in Reahl are defaulted. This means that you can easily run a development server without having to create lots of configuration files because these default settings will be used instead.
Defaults are thus chosen to work in a development environment. Some of these defaults do not make sense in a production environment. For this reason, when a Reahl server starts up, it warns about such “Dangerous defaults”–values that are defaulted for a development environment. The idea is that in a production system, you are expected to set these explicitly, and not rely on the defaulted value.
In Reahl 3.2 when you run a system in production it will fail to start up if any such dangerous default value is not set explicitly. Previously it would start, but with a warning.
Furthermore, some important configuration settings that previously were not defaulted are now defaulted:
|Setting||Config file||Dangerous default|
If you are running a production system, you will have to explicitly set these after upgrading before your system will start again.
The Reahl 3.1 series allowed use of the reahl-web-elixirimpl egg which was distributed with Reahl 2.x to ease transition from the 2 to 3 series. In Reahl 3.2 this usage of some older 2.x version eggs is no longer supported.
Changes to existing layout tools¶
In the process of having to support Bootstrap, our existing concept of
PageColumnLayout has grown too.
PageColumnLayout has too much responsibility. It structures a page
with header, footer etc but it also structures the content area of the
page into columns. In order to do this,
hard-codes the use of a
reahl.web.pure.ColumnLayout and we wanted to be able
to use it with a
reahl.web.layout.PageLayout solves this problem by
only taking responsibility for the page itself (header, content,
footer). You can optionally also set up a
PageLayout with a separate
Layout for each of it parts (header, document, content,
footer). Detailed layout of each part is thus decoupled from the
PageLayout itself and delegated to whatever
Layout you specify for
- jQuery from 1.8.1 to 1.11.2 (with jquery-migrate 1.2.1 added)
- jquery-blockui to 2.70.0
The versions of some external dependencies were updated:
- Babel from 1.3 to 2.1
- docutils max version 1.12 to < 1.13
- selenium max version from < 2.43 to < 3
Development web server¶
The development web server (invoked with
reahl serve) now has the
ability to watch for file changes in multiple directories, and restart
itself when a change is detected.
reahl serve -h
Dealing with front-end libraries¶
reahl.web.libraries module was added for dealing with such
front-end libraries. The same mechanism is now also used internally by
HTMLElement could be set up so that it is refreshed
via ajax if any of its
query_fields() changed. This was done by
enable_refresh(). These ideas were refined a little:
enable_refresh() can now be given a list of the
query_fields() so that
HTMLElement will only be refreshed if the changing query_field
is included in the list sent to
enable_refresh(). Others are ignored.
FieldSet could be constructed with the keyword argument label_text
in which case a
Label would be added at the
start of the
FieldSet. This is an incorrect usage of
according to the HTML specification, hence this usage is now deprecated.
This was done to allow one to use a
Layout on the
would not be possible before. (A
Layout has to be attached
Table before data is added to the
Table so that the
added rows adhere to the
One of the defining features of a
Fixture is that it can have
methods for creating new objects for use in the test. All the
arguments of these methods are keyword arguments with default values
so that you can easily create a new object with default setup or
choose to create a instance that only customises values important to
def new_person(self, name='Jane', surname='Doe): return Person(name, surname)
Such a method can be called in different ways:
jane = fixture.new_person() john = fixture.new_person(name=John)
If you access an attribute on a
Fixture with the new_ prefix
chopped off, the corresponding new_ method is called without
arguments to create and instance to be returned. This instance is
then stored so that subsequent calls keep returning that same
assert fixture.person is fixture.person
In the past, singleton instances created like this were never torn
down. In most cases it is not necessary to tear them down because the
Fixture is thrown away after a test. We also abort the
database between each of our tests, so that database-persisted
instances are also cleaned up.
Sometimes (albeit rarely) it is useful to be able to tear down some of
these singleton instances explicitly when the
Fixture itself is
being torn down. In order to do this, you can now have a corresponding
method prefixed with del_ which will be called at
def del_person(self, person): # do stuff to clean up after person
The del_ methods are called when tearing down the
any other tear down mechanisms are invoked, and in reverse order of
creation of each singleton instance.