tandem/camper
tandem
/
camper
2
0
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity
camper/web/templates/admin/media/upload.gohtml

39 lines
1.4 KiB
Plaintext
Raw Normal View History

Manage all media uploads in a single place It made no sense to have a file upload in each form that needs a media, because to reuse an existing media users would need to upload the exact same file again; this is very unusual and unfriendly. A better option is to have a “centralized” media section, where people can upload files there, and then have a picker to select from there. Ideally, there would be an upload option in the picker, but i did not add it yet. I’ve split the content from the media because i want users to have the option to update a media, for instance when they need to upload a reduced or cropped version of the same photo, without an edit they would need to upload the file as a new media and then update all places where the old version was used. And i did not want to trouble people that uploads the same photo twice: without the separate relation, doing so would throw a constraint error. I do not believe there is any security problem to have all companies link their media to the same file, as they were already readable by everyone and could upload the data from a different company to their own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
<!--
SPDX-FileCopyrightText: 2023 jordi fita mas <jordi@tandem.blog>
SPDX-License-Identifier: AGPL-3.0-only
-->
{{ define "title" -}}
{{( pgettext "Upload Media" "title" )}}
{{- end }}
Add breadcrumb to all admin pages I tried to use ../, and ../../ to make the routes relatives, but it would not work well because the same page would have two URLs, one ending with slash and another without, and the relative links would be different on each case.
2024-01-21 21:44:04 +00:00
{{ define "breadcrumb" -}}
<li><a href="/admin/media">{{( pgettext "Media" "title" )}}</a></li>
{{- end }}
Manage all media uploads in a single place It made no sense to have a file upload in each form that needs a media, because to reuse an existing media users would need to upload the exact same file again; this is very unusual and unfriendly. A better option is to have a “centralized” media section, where people can upload files there, and then have a picker to select from there. Ideally, there would be an upload option in the picker, but i did not add it yet. I’ve split the content from the media because i want users to have the option to update a media, for instance when they need to upload a reduced or cropped version of the same photo, without an edit they would need to upload the file as a new media and then update all places where the old version was used. And i did not want to trouble people that uploads the same photo twice: without the separate relation, doing so would throw a constraint error. I do not believe there is any security problem to have all companies link their media to the same file, as they were already readable by everyone and could upload the data from a different company to their own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
{{ define "content" -}}
{{- /*gotype: dev.tandem.ws/tandem/camper/pkg/media.uploadForm*/ -}}
Add the upload form to the media picker It makes easier to upload new images from the place where we need it, instead of having to go to the media section each time. It was a little messy, this one. First of all, I realized that POSTint to /admin/media/picker to get the new media field was wrong: i was not asking the server to “accept an entity”, but only requesting a new HTML value, just like a GET to /admin/media/upload requests the form to upload a new media, thus here i should do the same, except i needed the query parameters to change the field, which is fine—it is actually a different resource, thus a different URL. Then, i thought that i could not POST the upload to /admin/media, because i returned a different HTML —the media field—, so i reused the recently unused POST to /admin/media/picker to upload that file and return the HTML for the field. It was wrong, because i was not requesting the server to put the file as a subordinate of /admin/media/picker, only /admin/media, but i did not come up with any other solution. Since i had two different upload functions now, i created uploadForm’s Handle method to refactorize the duplicated logic to a single place. Unfortunately, i did not work as i expected because uploadForm’s and mediaPicker’s MustRender methods are different, and mediaPicker has to embed uploadForm to render the form in the picker. That made me change Handle’s output to a boolean and error in order for the HTTP handler function know when to render the form with the error messages with the proper MustRender handler. However, I saw the opportunity of reusing that Handler method for editMedia, that was doing mostly the same job, but had to call a different Validate than uploadForm’s, because editMedia does not require the uploaded file. That’s when i realized that i could use an interface and that this interface could be reused not only within media but throughout the application, and added HandleMultipart in form. Had to create a different interface for multipart forms because they need different parameters in Parse that non-multipart form, when i add that interface, hence had to also change Parse to ParseForm to account for the difference in signature; not a big deal. After all that, i realized that i **could** POST to /admin/media in both cases, because i always return “an HTML entity”, it just happens that for the media section it is empty with a redirect, and for the picker is the field. That made the whole Handle method a bit redundant, but i left it nevertheless, as i find it slightly easier to read the uploadMedia function now.
2023-09-21 23:40:22 +00:00
<form id="mediaUpload" enctype="multipart/form-data" action="/admin/media" method="post" data-hx-boost="true">
Manage all media uploads in a single place It made no sense to have a file upload in each form that needs a media, because to reuse an existing media users would need to upload the exact same file again; this is very unusual and unfriendly. A better option is to have a “centralized” media section, where people can upload files there, and then have a picker to select from there. Ideally, there would be an upload option in the picker, but i did not add it yet. I’ve split the content from the media because i want users to have the option to update a media, for instance when they need to upload a reduced or cropped version of the same photo, without an edit they would need to upload the file as a new media and then update all places where the old version was used. And i did not want to trouble people that uploads the same photo twice: without the separate relation, doing so would throw a constraint error. I do not believe there is any security problem to have all companies link their media to the same file, as they were already readable by everyone and could upload the data from a different company to their own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
<h2>{{( pgettext "Upload Media" "title" )}}</h2>
{{ CSRFInput }}
<fieldset>
{{ with .File -}}
<label>
{{( pgettext "File" "input" )}}
<input type="file" name="{{ .Name }}"
required {{ template "error-attrs" . }}><br>
</label>
<p>{{ printf (gettext "Maximum upload file size: %s") (.MaxSize | humanizeBytes) }}</p>
{{ template "error-message" . }}
{{- end }}
</fieldset>
<footer>
<button type="submit">{{( pgettext "Upload" "action" )}}</button>
<progress value="0" max="100"></progress>
</footer>
</form>
Export camperUploadForm function I did not remember that the file was loaded as a module, so i have to export it in order to use from the <script> in media. That <script> needs to be also a module and explicitly import the function; since it is already loaded, the browser does not load the file again.
2023-09-24 01:19:46 +00:00
<script type="module">
Add the application’s version to the footer This is mostly because it is required for the “Digital Kit”, but it also works in our favor because now i can version the URL to the static resources. Go 1.18 adds the info from git if the package is build from a git repository, but this is not the case in OBS, so i instead relay on a constant for the version number. This constant is “updated” by Debian’s rules, mostly due to the discussion in [0]. [0]: https://github.com/golang/go/issues/22706
2024-01-21 19:50:04 +00:00
import {camperUploadForm} from "/static/camper.js?v={{ camperVersion }}";
Export camperUploadForm function I did not remember that the file was loaded as a module, so i have to export it in order to use from the <script> in media. That <script> needs to be also a module and explicitly import the function; since it is already loaded, the browser does not load the file again.
2023-09-24 01:19:46 +00:00
camperUploadForm(document.getElementById('mediaUpload'));
</script>
Manage all media uploads in a single place It made no sense to have a file upload in each form that needs a media, because to reuse an existing media users would need to upload the exact same file again; this is very unusual and unfriendly. A better option is to have a “centralized” media section, where people can upload files there, and then have a picker to select from there. Ideally, there would be an upload option in the picker, but i did not add it yet. I’ve split the content from the media because i want users to have the option to update a media, for instance when they need to upload a reduced or cropped version of the same photo, without an edit they would need to upload the file as a new media and then update all places where the old version was used. And i did not want to trouble people that uploads the same photo twice: without the separate relation, doing so would throw a constraint error. I do not believe there is any security problem to have all companies link their media to the same file, as they were already readable by everyone and could upload the data from a different company to their own; in other words, it is not worse than it was now.
2023-09-20 23:56:44 +00:00
{{- end }}