First set of fixes to revive Django-based GUI code #695
Conversation
robertbartel
force-pushed
the
f/revise_django_gui/fix_broken_1
branch
from
ff349ef to
3044651
Compare
| <link rel="shortcut icon" type="image/png" href="{% static 'common/img/favicon.png' %}"/> | ||
| <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script> | ||
| <link rel="stylesheet" href="{% static 'common/css/base.css' %}"/> | ||
| <link rel="stylesheet" href="{% static 'css/master.css' %}"/> |
There was a problem hiding this comment.
be careful - this is mixing and matching resources. css/master.css is the stylesheet for the root level master.html template. common/css/base.css is the stylesheet for base.html.
There was a problem hiding this comment.
I think in this case that is what I wanted to do here, though I appreciate the cautious eye. I felt like we should start from the same styling throughout, so I was trying to move to that in this template base. That said, I could be talked into deferring on this if we think it's problematic to do it until it's also time to clean up some of the redundant files (which I was avoiding at the moment).
There was a problem hiding this comment.
You might be better off changing to base template to master.html on the other templates rather than altering what css base.html is referencing. I haven't made the switch, so it might be fine, but both css files and templates are making assumptions based on what page elements are present.
You have the right idea, though. Switching what template you're inheriting from might work better here, though.
There was a problem hiding this comment.
Yeah, if I'm remembering correctly, I started off by switching the base template, but moving from base.html caused some problem with pages' scripts. Swapping in the CSS change ended up being easier to follow along with and appeared to have fewer immediate side effects than carefully tweaking what seemed to be a good chunk of the Javascript setup (and hoping there wasn't something else needed after that).
Regardless, there isn't going to be a clean fix until we overhaul a good chunk of things. My goal at moment is to be minimalist and do just enough to get things working again, albeit with some attention paid to not laying any seriously traps for us to fall into later.
Marking several utility functions (used by some broken places in GUI code) as deprecated, largely because they don't actually work.
Adding required STATIC_ROOT to be main static directory, and removing the addition of this directory in things scanned by the static file finders (i.e., since root, have other found things put here); this was needed to fix issues with static files from main model exec GUI app, which were not being found with previous config.
Adding daphne to dependencies.txt to install this requirment in GUI image build.
Moving base maas config html template to use css/master.css instead of common/css/base.css for consistent presentation.
Fixing some GUI classes that were broken and not update after changes to dmod.communication package, and then re-added URL to Django config that were taken out due to the previous classes breaking.
Hard-coding reasonable defaults for superuser setup values needed to get previously existing migration to work.
Making sure to put it after lines that export the SQL_PASSWORD as needed.
robertbartel
force-pushed
the
f/revise_django_gui/fix_broken_1
branch
from
3044651 to
208e190
Compare
A set of changes to get older, Django-based GUI components for map and job configuration at least mostly loading and rendering properly, whereas before nothing or almost nothing would appear.
A few things in particular to point out:
This is likely the first of several changes necessary to get things functional again.