darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-10 01:55:41 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
eb0ce31253df35aba0aeebfcfa6fd3d4cfeaa1ac
notifications-admin/app/templates/views/jobs/job.html

25 lines
776 B
HTML
Raw Normal View History

Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
{% extends "withnav_template.html" %}
{% from "components/banner.html" import banner %}
Make a macro for the AJAX update module This is less repetitive than typing out the HTML with all its attributes every time. It also lets us wrap up the idea of ‘finished’ as a parameter, so the AJAX code will only be initiated when it’s needed, eg if a job is still processing.
2016-06-28 09:21:46 +01:00
{% from "components/ajax-block.html" import ajax_block %}
Add a back to template link on job page When you’ve sent message(s) using a template, often the next thing you want to do is go and send the same template again, or edit it. Currently there’s no way of getting to a template from a job except for going back to the list of templates and re-finding it. This commit adds a link at the bottom of the job page that gives you a shortcut back to the individual template, where you can find actions like edit/send/etc.
2017-03-22 10:55:15 +00:00
{% from "components/page-footer.html" import page_footer %}
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
Include service name in page `<title>` In pages specific to a service (e.g. dashboard and sub pages) the title needs to distinguish which service it applies to. This is mainly to give context to screen reader users who could be managing multiple services. Implementing this uses template inheritance: `page_title` includes `per_page_title` includes `service_page_title` ‘GOV.UK Notify’ is inserted into every page title. Pages that set `service_page_title` get the service name inserted too.
2017-02-13 10:45:15 +00:00
{% block service_page_title %}
{{ uploaded_file_name }}
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
{% endblock %}
{% block maincolumn_content %}
<h1 class="heading-large">
{{ uploaded_file_name }}
</h1>
Show confirmation after pressing big green button There’s no immediate feedback with letter jobs, unlike email or text messages jobs where you see the numbers starting to tick over straight away. We need to reassure the user that the thing they asked us to do (send letters) is underway. ‘Printing’ feels like the natural first state of the letter-making process. So this commit adds a banner to tell the user that printing is the thing that’s happening.
2017-07-13 11:28:37 +01:00
{% if just_sent %}
{{ banner('We’ve started printing your letters', type='default', with_tick=True) }}
{% else %}
{{ ajax_block(partials, updates_url, 'status', finished=finished) }}
{% endif %}
Derive markup dashboard from rendered partials This commit extends the `ajax_block` component to take a `dict` of partials, from which it can select the partial matching its `key` argument and print its HTML to the page. This means that the same markup is only rendered in one place, rather than in two (individually in the JSON endpoint and as `include`s in the parent template).
2016-06-28 11:23:43 +01:00
{{ ajax_block(partials, updates_url, 'counts', finished=finished) }}
{{ ajax_block(partials, updates_url, 'notifications', finished=finished) }}
Make job page poll for updates This is a first go at having the job page update without refreshing. The approach I’ve taken is to do all the rendering of HTML on the server side, rather than use a Javascipt templating engine like mustache. This ensures that we don’t have to maintain two sets of templates. So the approach is to split the job page into partials. These partials can then: - be included in the job page to render the whole page - be rendered indivudually and then returned as a blob of HTML inside a JSON response Then I’ve added a Javascript module which looks for areas of the page that should be reloaded. For each area of the page it will poll a URL and re-render that section of the page when it gets new HTML. It implements some throttling so that API calls will never happen more frequently than 0.67 times/second.
2016-03-02 17:36:20 +00:00
{% endblock %}
Reference in New Issue Copy Permalink