Use request.session storage instead of (most of) the current views.py global variables

[bdklahn]

I think the global variables are causing the issues of dataset pollution between sessions (e.g. even an additional private browsing tab, on the same computer).

PEpiTA/webdesign/polls/views.py

Lines 22 to 33 in 36a2966

	file_path = ''
	input_ts = pd.DataFrame()
	pp_ts = pd.DataFrame()
	csvname = ''
	freq = 'D'
	csvtime = ''
	context = {}
	csvtype = ''
	datamindate = ''
	datacurmindate = ''
	datamaxdate = ''
	datacurmaxdate = ''

PEpiTA/webdesign/polls/views.py

Line 53 in 36a2966

global file_path, input_ts, pp_ts, csvname, freq, csvtime, context, csvtype, media_path, analytical_summary_path, categorize_output_path, zip_path, datamindate, datamaxdate, datacurmindate, datacurmaxdate

Global variables are generally a bad idea in any software engineering. It is almost always better/safer to explicitly pass things in, via function parameters, and utilize return values.

"Global variables allow you to share data across multiple functions, which can be useful in some situations. However, you should use this type of variable carefully and sparingly to avoid writing code that’s difficult to understand, debug, test, and maintain."
https://realpython.com/python-use-global-variable-in-function/

I believe the current situation makes it possible for an uploadbutton branch . . .

PEpiTA/webdesign/polls/views.py

Line 90 in 36a2966

if request.method == 'POST' and 'uploadbutton' in request.POST:

. . . in one session, to clobber the input_ts (and csvname, etc.) variable data of a subsequent evocation of a runbutton branch . . .

PEpiTA/webdesign/polls/views.py

Line 136 in 36a2966

if request.method == 'POST' and 'runbutton' in request.POST:

. . . in another session.

Session data is already set up to utilize server tmp storage. Django is also already configured to have session variables available to html templates. e.g.

In views.py index(request) function, we could do things like . . .

sess = request.session
sess.setdefault('csvname', '')

(etc.)

In index.html template:
{ request.session.csvname }

So, we might not even need to construct a "context" dictionary, and pass it to the render function. Maybe just add anything useful to the session dictionary.

Apparently, though, a session storage update is only automatically triggered by key value changes at the top level. If the content of a nested container (e.g. request.session['some_dict']['val1'] = 'new_val') is changed, that will require a manual triggering of an update, by . . .
request.session.modified = True
So it might be easiest/safest to just try to put things as basic data types, at the top level (e.g. not make a nested context dictionary one of the session key values).

Any utility functions called from index() could be passed the session dictionary, and get and set things from that.
e.g. here:

PEpiTA/webdesign/polls/views.py

Lines 321 to 322 in 36a2966

	def readfile(filename):
	global input_ts, csvtype

Does that make sense, @ajs997 (@srinivvenkat, @bryanleroylewis ) ?

It is probably even problematic to use a globally-accessable "figures" directory, under the "media" dir.

Note: Check the end of #9 (comment) for maybe a better way of storing the input_ts data.

[bdklahn]

It occurs to me . . . It's probably best to have the code utilize any "global" state, as little as possible. -even if it is per session. I.e. ideally try and reduce the number of those original variables to 3 or less. Pass things into functions and utilize return values, whenever possible.
It would be best to have things put in functions, with clear return values, rather than updating session variables as side-effects.
We could still assign the result from calling functions, using returned tuples if necessary for multiple changes. But, probably, the only place even a session variable should be used is as a session dictionary being passed in to a function. Helper functions probably shouldn't update the session dictionary internally. The/a top level function should do that from the helper function's return values.

Again, we might use functools cache if we want/need some stuff loaded into memory. I would assume that if a DataFrame is passed into a function, it would only use the cached data for output (e.g. what's in the return value), if the DataFrame function parameter was referencing the exact same df object, in memory.