tandem
/
numerus
2
0
Fork 0
Code Issues 37 Pull Requests Packages Projects 1 Releases 1 Wiki Activity
numerus/web/template/profile.gohtml

40 lines
1.3 KiB
Plaintext
Raw Normal View History

Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
{{ define "title" -}}
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
{{( pgettext "User Settings" "title" )}}
Move page titles to their respective templates I have been thinking about that, and it does not make that much sense to have the titles in the Go source anymore: most of them are static text that i have to remember to set in the controller each time, and when the time come i have to face a dynamic title i am sure i will manage with only the template capabilities—worst comes worst, i can always define a function. On the other hand, there is no way i can define a template without its title and i know that everytime that template is used, no matter what controller rendered it, it will always have that title.
2023-01-31 12:07:17 +00:00
{{- end }}
Use “layouts” for the common HTML between pages Had to call xgettext on Go source files because now the title comes from there, as i assume i will have titles like "Invoice #INVxxxx" that have to come from the database that the template does not know.
2023-01-22 20:41:50 +00:00
{{ define "content" }}
Add cross-request forgery detection I use the ten first digits of the cookie’s hash, that i believe it is not a problem, has the advantage of not expiring until the user logs out, and using a per user session token is explicitly allowed by OWASP[0]. [0]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern
2023-02-02 10:39:34 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.profileForm*/ -}}
Add breadcrumbs
2023-02-03 12:58:10 +00:00
<nav>
<p>
<a href="{{ companyURI "/" }}">{{( pgettext "Home" "title" )}}</a> /
<a>{{( pgettext "User Settings" "title" )}}</a>
</p>
</nav>
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
<section class="dialog-content">
<h2>{{(pgettext "User Settings" "title")}}</h2>
<form method="POST">
Add cross-request forgery detection I use the ten first digits of the cookie’s hash, that i believe it is not a problem, has the advantage of not expiring until the user logs out, and using a per user session token is explicitly allowed by OWASP[0]. [0]: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#synchronizer-token-pattern
2023-02-02 10:39:34 +00:00
{{ csrfToken }}
Validate profile form and use templates for fields Let’s start first with a non-fancy validation method with just if conditionals instead of bringing yet another complicated library. I hope i do not regret it. I wanted to move all the input field to a template because all that gobbledygook with the .input div and repeating the label in the placeholder was starting to annoy me. Now with error messages was even more concerning. I did not know whether the label should be a part of the input fields or something that the template should do. At the end i decided that it makes more sense to be part of the input field because in the error messages i use that same label, thus the template does not have a say in that, and, besides, it was just easier to write the template. The same with the error messages: i’ve seen frameworks that have a map with the field’s id/name to the error slice, but then it would be a bit harder to write the template. I added AddError functions instead of just using append inside the validator function, and have a local variable for whether it all went OK, because i was worried that i would leave out the `ok = false` in some conditions. I had started writing “constructors” functions for InputField and SelectField, but then had to add other methods to change the required field and who knows what else, and in the end it was easier to just construct the field inline.
2023-01-31 14:40:12 +00:00
<fieldset class="full-width">
<legend>{{( pgettext "User Access Data" "title" )}}</legend>
{{ template "input-field" .Name }}
{{ template "input-field" .Email }}
</fieldset>
<fieldset class="full-width">
<legend>{{( pgettext "Password Change" "title" )}}</legend>
{{ template "input-field" .Password }}
{{ template "input-field" .PasswordConfirm }}
</fieldset>
<fieldset>
<legend id="language-legend">{{( pgettext "Language" "title" )}}</legend>
{{ template "select-field" .Language }}
<button type="submit">{{( pgettext "Save changes" "action" )}}</button>
</fieldset>
</form>
</section>
Use “layouts” for the common HTML between pages Had to call xgettext on Go source files because now the title comes from there, as i assume i will have titles like "Invoice #INVxxxx" that have to come from the database that the template does not know.
2023-01-22 20:41:50 +00:00
{{- end }}