Misfeature - not a bug. Rather the misfeature is characterized as, "We did it that way on purpose, but it turned out to be a bad idea."
Joe, ca. 1988
In the Misfeature - Part 1
post, we refactored BLOX project code to adapt to the change from separate rhyme and stanza tables to a single stanza
table, concentrating mostly on the huddle.py
This post is dedicated to consolidating the rhyme_views.py
modules into a single stanza_views.py
module that manages data entry for both the Rhymes and Stanzas.
Where the previous post followed a series commits to the BLOX repository, here we were able to effect all the changes we wanted with only a single (fairly large) commit.
Commit e7f3ad7 - stanza_views.py
The mechanics of changing the stanza_views.py
module are pretty straightforward: 1) step through the Flask routes in the rhyme_views.py
module one at a time, starting with the '/new_rhyme/' route; 2) alter the corresponding Flask route in the stanza_views.py
module to take variable '<sid>' and '<brand>' parameters; and 3) for separate handling of Rhymes and Stanzas, use conditionals based on the brand
Most of the changes to stanza_views.py
followed this same pattern, but there were a few exceptions.
We added a '/plus_stanza/<brand>
' route to stanza_views.py
, mimicking and replacing the '/plus_rhyme/
' route from rhyme_views.py
. The fun part about this change is that previously there was no "plus_stanza" option. The consolidation of the Rhyme and Stanza handling made it readily available, though, and we took advantage (lines 84-117).
The same thing happened to enable an easy extension of the "Upd" button from the rhyme_views.py
module to the stanza_views.py
module (lines 188-191).
Salubrious effects of modularization and hiding.
Many of the changes to the HTML templates were coordinated with the view functions in the stanza_views.py module to add information to the POST actions in the forms and matches them with the Flask route parameters. For example, the change in new_rhyme.html at line 25 ("/add_rhyme/" changed to "/add_stanza/rhyme") or the similar change to edit_spiel.html at line 115.
Other changes were made to conform template element names to the new attribute names in the Rhyme and Stanza classes, e.g., "c_mold" and "rhyme_text" changed to "part_1" and "part_2" in new_rhyme.html.
Bits and Pieces
As mentioned at the end of the Misfeature_1 post, this single commit was implemented in small steps - and we were able to keep the application running through each of those steps. That was not the plan or goal when we started the changes for this commit. We just forgot that we were working in a live code environment until we were a couple of steps in. Because the needed changes were pretty clear and could be attacked in a relatively simple pattern, we decided to give it a shot. Worked out great - but we don't recommend doing development that way.
In the next post, we'll describe setting up a simple, on-system deployment methodology to separate production code and data from development code and data.
This post is based on the BLOX
This post will be a lot easier to follow if you open up a separate screen to review the commits
in the BLOX repository.
Misfeature - Part 1
: consolidates the rhyme
table and the stanza
table from the original BLOX database into a single stanza
table with an additional brand
field to distinguish between Rhymes and Stanzas.
Misfeature - Part 3
: separate update of the spiel
table to support changes to the generate and publication operations.
Almost every commit includes tweaks and toggles that we don't bother to discuss in the relevant posts. Examples of tweaks in this post are the coordinated changes to the __init__.py and generate.py modules to firm up the invocation of the system call to the freeze.py module in the external_generation() function. The commit also includes toggling the logger-level in the huddle.py and dbx_seed.py modules.
In order to keep the static page generation process operating in an anticipated separate production environment, we took an easy way out by adding code to the __init__.py module so that we can find the freeze.py module to perform the generation. We'll fix that when we put a better separation of development and production in place.
Ditto for the freeze.py module.