darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-07 15:48:24 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
d22b2f678dff365db79d1a9610efbb24e9913d13
notifications-admin/app/templates/partials/jobs/notifications.html

44 lines
1.2 KiB
HTML
Raw Normal View History

Put same info in both tables of notifications We have tables listing notifications on: - the job page - the ‘activity’ page Previously that had subtly different information, in a different order. This commit makes them exactly the same.
2016-06-09 10:25:52 +01:00
{% from "components/table.html" import list_table, field, right_aligned_field_heading, date_field, row_heading %}
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
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
{% if notifications %}
<div class="dashboard-table">
{% endif %}
Make a function for parsing `help` query param Our templates are a littered with `request.args.get('help', '0')`. This commit refactors these into a single helper method, which can be used by the view functions, then passed to the template. This makes the templates cleaner, and should make it easier to refactor `help` out of the query parameters entirely in the future.
2016-07-05 11:39:07 +01:00
{% if notifications and not help %}
Make the job page look close to the activity page We can’t filter a job by notification status yet, but we can: - put the download link in the same place - make the table line up the same
2016-06-13 14:13:23 +01:00
<p class="bottom-gutter">
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
<a href="{{ url_for('.view_job_csv', service_id=current_service.id, job_id=job.id, status=status) }}" download="download" class="heading-small">Download as a CSV file</a>
Make the job page look close to the activity page We can’t filter a job by notification status yet, but we can: - put the download link in the same place - make the table line up the same
2016-06-13 14:13:23 +01:00
&emsp;
Delivery information is available for 7 days
</p>
{% endif %}
Remove redundant `if` statement on job page We had this if statement to lay out the table differently with and without row numbers. Since we don’t show row numbers at all, this isn’t needed.
2016-06-09 11:26:45 +01:00
{% call(item, row_number) list_table(
notifications,
caption=uploaded_file_name,
caption_visible=False,
Make jobs filterable by notification status We can filter all notifications by status already. This commit reuses the same code to filter the notifications for a job by status. This means that, visually we can show the count on a job the same as we do for all notifications, which is similar to how we show the counts on the dashboard, so hopefully it feels like a bit more of a solid thing. This also applies to CSV downloads and AJAX updates, which will inherit any filtering that their parent page has applied.
2016-06-08 16:34:26 +01:00
empty_message="No messages to show",
Remove redundant `if` statement on job page We had this if statement to lay out the table differently with and without row numbers. Since we don’t show row numbers at all, this isn’t needed.
2016-06-09 11:26:45 +01:00
field_headings=[
'Recipient',
'Time',
'Status'
],
field_headings_visible=False
) %}
{% call row_heading() %}
{{ item.to }}
{% endcall %}
{{ date_field(
(item.updated_at or item.created_at)|format_datetime_short
) }}
{% call field(
align='right',
status=item.status|format_notification_status_as_field_status
Patch update sections of the page on AJAX Currently, when we update a section of the page with AJAX we replace the entire HTML of the section with the new HTML. This causes problems: - if you’re trying to interact with that section of the page, eg by inpecting it, clicking or hovering an element - (probably) for screenreaders trying to navigate a page which is changing more than is necessary This commit replaces the call to `.html()` with a pretty clever library called diffDOM[1]. DiffDOM works by taking a diff of the old element and the new element, then doing a patch update, ie only modifying the parts that have changed. This is similar in concept to React’s virtual DOM, while still allowing us to render all markup from one set of templates on the server-side. 1. https://github.com/fiduswriter/diffDOM
2016-04-27 09:28:42 +01:00
) %}
Remove redundant `if` statement on job page We had this if statement to lay out the table differently with and without row numbers. Since we don’t show row numbers at all, this isn’t needed.
2016-06-09 11:26:45 +01:00
{{ item.status|format_notification_status(item.template.template_type) }}
Patch update sections of the page on AJAX Currently, when we update a section of the page with AJAX we replace the entire HTML of the section with the new HTML. This causes problems: - if you’re trying to interact with that section of the page, eg by inpecting it, clicking or hovering an element - (probably) for screenreaders trying to navigate a page which is changing more than is necessary This commit replaces the call to `.html()` with a pretty clever library called diffDOM[1]. DiffDOM works by taking a diff of the old element and the new element, then doing a patch update, ie only modifying the parts that have changed. This is similar in concept to React’s virtual DOM, while still allowing us to render all markup from one set of templates on the server-side. 1. https://github.com/fiduswriter/diffDOM
2016-04-27 09:28:42 +01:00
{% endcall %}
Remove redundant `if` statement on job page We had this if statement to lay out the table differently with and without row numbers. Since we don’t show row numbers at all, this isn’t needed.
2016-06-09 11:26:45 +01:00
{% endcall %}
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
{% if notifications %}
</div>
{% endif %}
Reference in New Issue Copy Permalink