Open SsorWayfinder opened 4 years ago
De-coupling the front-end and back-end could save a lot of effort down the line. Could you elaborate on what you imagine that might look like?
I don't seem to have the current spread sheet anymore but loosely based on the one in the repo:
PublicComment (data structure containing everything related to the comment)
I see. So like a ViewModel?
Like this (in microcosm)?
<form action='POST', method="{{ url_for('test') }}">
<input type="text" name="example" />
...
<input type="submit" />
</form>
<div>
<h2>{{ alpha.example }}</h2>
</div>
class Alpha:
def __init__(self, example):
self.example = example
@bp.route('/', methods=('GET', 'POST'))
def test():
if request.method == 'POST':
example = request.form['example']
alpha = Alpha(example)
return render_template('example.html', alpha=alpha)`
Sorry I've been mia, I've been moving.
I was thinking of this a more of an internal thing that could be then transformed into the view or into the format of the google doc, or whatever other form we might need this data for.
Instead of "speaker" consider "contributor" so we can later support input from online forms and emails. And eventually neuralink. :)
Also, "in_atlanta" could be called "in_city" or "in_metroarea" to allow for reuse with other cities. Or just call it "city" and save the value "Atlanta".
If we create an agreed upon data structure the front end can be worked on without worrying were the data comes from or how it will be presented, and the data can be retrieved and sent without worrying about the specifics of how it will be used. This also can protect the front end from any changes in how the data is held (in the spreadsheet or otherwise), only requiring the transformation into the data structure to be fixed.