Notes on Design Decisions

This if for posterity and/or future refactor opportunities. It may also shine some light on why certain things are the way they are.

Templating: client vs server side.

Flask, via Jinja2, provides a means to extend html templates with data structures created in Python. This in a way is scripting the building of html. jQuery, and other front-end javascript frameworks, also provide ways to script the building of html.

Given this is a Flask app, and we're creating a lot of form data, I could have used a lot of Jinja2 in our html templates to build out completed forms - e.g., when loading a Fish Fry into the editing form.

It would have made the roles of the different languages clearer if I had: Python/Flask for server-side templating. Limit Javascript to DOM manipulation and other things that only need to happen on the client.

I started down this path with the Fish Fry Form, but it got messy and repetitive very quickly. Every form field had lines of Jinja2 interjected with deep calls in the Fish Fry class properties (from the Python side), all mixed in with HTML. And it had to be done manually for every field. Too much.

In the case of the Form itself, it was just easier to pass all the Fish Fry data from Python/Flask to an Javascript object via json, and use that to manipulate form fields on the client side. Since the form id's match the names of the Fish Fry attributes, I could programmatically modify form values with jQuery by simply looping through the attributes, calling each form element by its id, which matched the attribute name.

The only messiness is that in one place--the events portion of the form--do I need to have some html mixed in with javascript for the purposes of building out a list of items. It's only 4 lines, versus the several dozen of non-html templating I would have needed to include in my form html following the server-side based route.