Feat: UI templates for the districts application

[lalver1]

Closes #68

This PR adds UI placeholders for the districts application.

Reviewing

Click around to test out the navigation sidebar to go from all districts to a particular district.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
pems
urls.py
pems/core
context_processors.py
middleware.py
urls.py
pems/districts
urls.py
views.py
pems/streamlit_sample
urls.py
Project Total

This report was generated by python-coverage-comment-action

[lalver1]

• I'll have to review the naming/organization of the templates' context soon since it will grow quickly and it'll need to be better organized, but I think for the districts app this may work.
• The borders on the form, chart, details and map divs will be removed, they will only be used temporarily to help us develop the layout.

[thekaveman]

I'll have to review the naming/organization of the templates' context soon since it will grow quickly and it'll need to be better organized, but I think for the districts app this may work.

I've been thinking about this some as it relates to our context strategy and class-based views.

A couple of ideas I'm kicking around:

Hierarchical context

It is OK (and maybe preferable for organization) to have hierarchical context values using dicts e.g.

def get_context_data(self, **kwargs):
    context = super().get_context_data(**kwargs)

    districts_ctx = {}
    districts_ctx["all"] = District.objects.all()

    context["districts"] = districts_ctx
    return context

Then in the template:

<h1>Districts</h1>
{% for district in districts.all %}
   ...
{% endfor %}

Standard context

We might want to think about standardizing on some of the top-level keys. E.g. if we have a class-based view that adds context via a get_context_data() implementation, maybe we should always put that in the view top-level context?

class SomeView(TemplateView):
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)

        custom_ctx = {}
        custom_ctx["something"] = "data"  

        context["view"] = custom_ctx
        return context

This way we can easily distinguish between that from views and that from context processors in the template:

<h1>{{ view.title }}</h1>
<p>{{ view.content }}</p>
<p>{{ common.content }}</p>

[thekaveman]

Left some comments.

I think it's time to look into more of the class-based views. A lot of the work here would come for free by using some more sophisticated views beyond TemplateView.

[lalver1]

Thanks for the suggestions @thekaveman!
I implemented a shared context (using your Hierarchical context idea) in 7b93b1f and switched to use a DetailView for DistrictView in 5cb85e2.

[thekaveman]

👍