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

112 lines
4.5 KiB
Plaintext
Raw Normal View History

Add the bare-bones form for invoices
2023-02-11 21:16:48 +00:00
{{ define "hidden-field" -}}
Add the form to add products to an invoice and create invoices too Still missing: the invoice number, that requires more tables and possibly a PL/pgSQL function to do it properly.
2023-02-12 20:06:48 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.InputField*/ -}}
<input type="hidden" name="{{ .Name }}"
Add the bare-bones form for invoices
2023-02-11 21:16:48 +00:00
{{- range $attribute := .Attributes }} {{$attribute}} {{ end }}
Use .String in hidden-field template, so that it works for TagsField too
2023-03-28 08:01:41 +00:00
value="{{ .String }}">
Add the bare-bones form for invoices
2023-02-11 21:16:48 +00:00
{{- end }}
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
{{ define "input-field" -}}
Add the form to add products to an invoice and create invoices too Still missing: the invoice number, that requires more tables and possibly a PL/pgSQL function to do it properly.
2023-02-12 20:06:48 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.InputField*/ -}}
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
<div class="input {{ if .Errors }}has-errors{{ end }}">
Add template for InputField of type textarea
2023-02-07 14:28:22 +00:00
{{ if eq .Type "textarea" }}
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
<textarea name="{{ .Name }}" id="{{ .Name }}-field"
Add template for InputField of type textarea
2023-02-07 14:28:22 +00:00
{{- range $attribute := .Attributes }} {{$attribute}} {{ end }}
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
{{ if .Required }}required="required"{{ end }} placeholder="{{ .Label }}"
>{{ .Val }}</textarea>
Add template for InputField of type textarea
2023-02-07 14:28:22 +00:00
{{ else }}
<input type="{{ .Type }}" name="{{ .Name }}" id="{{ .Name }}-field"
{{- range $attribute := .Attributes }} {{$attribute}} {{ end }}
{{ if .Required }}required="required"{{ end }} value="{{ .Val }}" placeholder="{{ .Label }}">
{{ end }}
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
<label for="{{ .Name }}-field">{{ .Label }}</label>
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
{{- if .Errors }}
<ul>
{{- range $error := .Errors }}
<li>{{ . }}</li>
{{- end }}
</ul>
{{- end }}
</div>
{{- end }}
{{ define "tags-field" -}}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.InputField*/ -}}
<div class="input {{ if .Errors }}has-errors{{ end }}" is="numerus-tags">
<input type="text" name="{{ .Name }}" id="{{ .Name }}-field"
{{- range $attribute := .Attributes }} {{$attribute}} {{ end }}
Add tags for contacts too With Oriol we agreed that contacts should have tags, too, and that the “tag pool”, as it were, should be shared with the one for invoices (and all future tags we might add). I added the contact_tag relation and tag_contact function, just like with invoices, and then realized that the SQL queries that Go had to execute were becoming “complex” enough: i had to get not only the slug, but the contact id to call tag_contact, and all inside a transaction. Therefore, i opted to create the add_contact and edit_contact functions, that mirror those for invoice and products, so now each “major” section has these functions. They also simplified a bit the handling of the VATIN and phone numbers, because it is now encapsuled inside the PL/pgSQL function and Go does not know how to assemble the parts.
2023-03-26 00:32:53 +00:00
{{ if .Required }}required="required"{{ end }} value="{{ .String }}" placeholder="{{ .Label }}">
Start the tag input custom element This is more or less the same as a multiselect, except that now it adds a list of string element that you write into the search element. It is supposed to fetch a list of tag suggestions from the server, but i have not implemented it yet.
2023-03-19 22:11:40 +00:00
<label for="{{ .Name }}-field">{{ .Label }}</label>
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
{{- if .Errors }}
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
<ul>
{{- range $error := .Errors }}
<li>{{ . }}</li>
{{- end }}
</ul>
Use a “proper” struct for the login form Similar to the profile form, the login form now parses and validates itself, with the InputField structs that the templates expect. I realized that i was doing more work than necessary when parsing fields fro the profile form because i was repeating the operation and the field name, so now it is a function of InputField. This time i needed extra attributes for the login form. I am not sure that the Go source code needs to know about HTML attributes, but it was the easiest way to pass them to the template.
2023-02-01 10:02:32 +00:00
{{- end }}
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
</div>
{{- end }}
Add the form to add products to an invoice and create invoices too Still missing: the invoice number, that requires more tables and possibly a PL/pgSQL function to do it properly.
2023-02-12 20:06:48 +00:00
{{ define "hidden-select-field" -}}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.SelectField*/ -}}
{{- range $selected := .Selected }}
<input type="hidden" name="{{ $.Name }}"
{{- range $attribute := $.Attributes }} {{$attribute}} {{ end }}
value="{{ . }}">
{{- end }}
{{- end }}
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
{{ define "select-field" -}}
Add the form to add products to an invoice and create invoices too Still missing: the invoice number, that requires more tables and possibly a PL/pgSQL function to do it properly.
2023-02-12 20:06:48 +00:00
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.SelectField*/ -}}
Reimplement the multiselect as a custom element What i really set off on was to refactor the multiselect’s x-data context to a separate JavaScript file. I did not see the need at first, thinking that it would not matter because it was used only in a template and i was not duplicating the code in my files. However, i then realized that having the context in the template means the visitor has to download it each and every time it accesses a form with a multiselect, even if nothing changed, and, worse, it would download it multiple times if there were many multiselect controls. It makes more sense to put all that into a file that the browser would only download and parse once, if the proper caching is set. Once i realized that, it was a shame that AlpineJS has no way to do the same for the HTML structure[0], for the exact same reasons: not wanting to download many times the same extra <template> and other markup required to build the control for JavaScript users. And then i remembered that this is supposed to be custom element’s main selling point. At first i tried to create a shadow DOW to replace the <select> with the same <div> and <ul> that i used with Alpine, but it turns out that <select> is not one of the allowed elements that can have a shadow root attached[0]. Therefore, i changed the custom element to extend the <div> for the <select> and <label> instead—the same element that had the x-init context—, but i would have to define or include all the styles inside the shadow DOM, and bring the lang attribute, for it to look like it did before. Out with the shadow DOM, and modify the <div>’s contents instead. At this point the code was so far removed from the declarative way that AlpineJS promotes that i did not see much value on using it, except for its reactivity. But, given that this is such a small component, at the end decided to write it all in plain JavaScript. It is more code, at least looking only at the code i had to write, but i love how i only have to add an is="numerus-multiselect" attribute to HTML for it to work. [0]: https://github.com/alpinejs/alpine/discussions/1205 [1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
2023-03-17 13:55:12 +00:00
<div class="input{{ if .Errors }} has-errors{{ end }}"{{ if .Multiple }} is="numerus-multiselect"{{ end -}}>
Handle tax details and new tax forms with structs and validation I implemented the Valuer and Scanner interfaces to InputField and SelectField for better passing values between the database and Go. I had a conflict with the Value name and renamed the struct member to Val. I also had to change the attributes array to be of type template.HTMLAttr or html/template would replace `form="newtax"` attribute to `zgotmplz="newtax"` because it deems it “unsafe”. I do not like having to use template.HTMLAttr when assigning values, but i do not know what else i can do now.
2023-02-01 13:15:02 +00:00
<select id="{{ .Name }}-field" name="{{ .Name }}"
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
{{- range $attribute := .Attributes }} {{$attribute}} {{ end -}}
Add grouping for form’s select field We will only allow to select a tax from each of the tax classes, but the user needs to know what class each tax belongs to, and grouping the taxes by class in the select helps with that.
2023-03-01 10:40:23 +00:00
{{ if .Multiple }} multiple="multiple"{{ end -}}
{{ if .Required }} required="required"{{ end -}}
Handle tax details and new tax forms with structs and validation I implemented the Valuer and Scanner interfaces to InputField and SelectField for better passing values between the database and Go. I had a conflict with the Value name and renamed the struct member to Val. I also had to change the attributes array to be of type template.HTMLAttr or html/template would replace `form="newtax"` attribute to `zgotmplz="newtax"` because it deems it “unsafe”. I do not like having to use template.HTMLAttr when assigning values, but i do not know what else i can do now.
2023-02-01 13:15:02 +00:00
>
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
{{- with .EmptyLabel }}
<option value="">{{ . }}</option>
{{- end}}
Add grouping for form’s select field We will only allow to select a tax from each of the tax classes, but the user needs to know what class each tax belongs to, and grouping the taxes by class in the select helps with that.
2023-03-01 10:40:23 +00:00
{{- $withinGroup := "" -}}
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
{{- range $option := .Options }}
Add grouping for form’s select field We will only allow to select a tax from each of the tax classes, but the user needs to know what class each tax belongs to, and grouping the taxes by class in the select helps with that.
2023-03-01 10:40:23 +00:00
{{- if ne .Group $withinGroup }}
{{- if ne $withinGroup "" }}
</optgroup>
{{ end }}
<optgroup label="{{ .Group }}">
{{- $withinGroup = .Group -}}
{{ end }}
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
<option value="{{ .Value }}"
Allow multiple taxes, and even not tax, for products It seems that we do not agree en whether the IRPF tax should be something of the product or the contact, so we decided to make the product have multiple taxes, just in case, and if only one is needed, then users can just select one; no need to limit to one.
2023-02-08 12:47:36 +00:00
{{- if $.IsSelected .Value }} selected="selected"{{ end }}>{{ .Label }}</option>
Add grouping for form’s select field We will only allow to select a tax from each of the tax classes, but the user needs to know what class each tax belongs to, and grouping the taxes by class in the select helps with that.
2023-03-01 10:40:23 +00:00
{{- end }}
{{- if ne $withinGroup "" }}
</optgroup>
Allow optional select with empty label This is not yet necessary, but the empty label is because i do not want to select a default tax for products—at least, not without a setting for it. Since i need to add the required attribute now to select, because otherwise the browser would allow sending that empty value, i did not want to do it unconditionally, just in case.
2023-02-05 13:06:33 +00:00
{{- end }}
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
</select>
<label for="{{ .Name }}-field">{{ .Label }}</label>
Handle tax details and new tax forms with structs and validation I implemented the Valuer and Scanner interfaces to InputField and SelectField for better passing values between the database and Go. I had a conflict with the Value name and renamed the struct member to Val. I also had to change the attributes array to be of type template.HTMLAttr or html/template would replace `form="newtax"` attribute to `zgotmplz="newtax"` because it deems it “unsafe”. I do not like having to use template.HTMLAttr when assigning values, but i do not know what else i can do now.
2023-02-01 13:15:02 +00:00
{{- if .Errors }}
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
<ul>
{{- range $error := .Errors }}
<li>{{ . }}</li>
{{- end }}
</ul>
Handle tax details and new tax forms with structs and validation I implemented the Valuer and Scanner interfaces to InputField and SelectField for better passing values between the database and Go. I had a conflict with the Value name and renamed the struct member to Val. I also had to change the attributes array to be of type template.HTMLAttr or html/template would replace `form="newtax"` attribute to `zgotmplz="newtax"` because it deems it “unsafe”. I do not like having to use template.HTMLAttr when assigning values, but i do not know what else i can do now.
2023-02-01 13:15:02 +00:00
{{- end }}
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
</div>
{{- end }}
Replace use of <select> for tags “and” and “or” with checkboxes I realized that using a select for just two, short, options is overkill: the select and its options use a lot more real state than the two radios, which can have tooltips (not yet, though). Since i am going to replace this field with a custom element that has a toggle-like aspect, i already added the is="numerus-toggle" attribute and use it for stying the non-JavaScript field.
2023-04-15 02:05:59 +00:00
{{ define "toggle-field" -}}
{{- /*gotype: dev.tandem.ws/tandem/numerus/pkg.ToggleField*/ -}}
“Integrate” the tags’ condition into the input field We have reconsidered the toggle thing and instead moved the selection into a little menu on top of the input, like the input’s label does à la Material Design. I just moved the checkboxes into a new details, that works as a menu, but i had to add the type="search" to the existing input in the tags field, or the CSS would style the checkboxes as well. I do not do anything when the checkbox selection changes because that already triggers a POST to the server that returns the new HTML with the checkbox changed, and the JavaScript only has to retrieve that new structure, exactly as it does in the initial rendering. Since we want to add a little description to the options, i no longer can use the same SelectOption in ToggleField, even though i could have reused the Group element, but that felt wrong.
2023-04-16 17:01:11 +00:00
<fieldset id="{{ .Name}}-field" class="input{{ if .Errors }} has-errors{{ end }}" is="numerus-toggle">
Replace use of <select> for tags “and” and “or” with checkboxes I realized that using a select for just two, short, options is overkill: the select and its options use a lot more real state than the two radios, which can have tooltips (not yet, though). Since i am going to replace this field with a custom element that has a toggle-like aspect, i already added the is="numerus-toggle" attribute and use it for stying the non-JavaScript field.
2023-04-15 02:05:59 +00:00
<legend>{{ .Label }}</legend>
“Integrate” the tags’ condition into the input field We have reconsidered the toggle thing and instead moved the selection into a little menu on top of the input, like the input’s label does à la Material Design. I just moved the checkboxes into a new details, that works as a menu, but i had to add the type="search" to the existing input in the tags field, or the CSS would style the checkboxes as well. I do not do anything when the checkbox selection changes because that already triggers a POST to the server that returns the new HTML with the checkbox changed, and the JavaScript only has to retrieve that new structure, exactly as it does in the initial rendering. Since we want to add a little description to the options, i no longer can use the same SelectOption in ToggleField, even though i could have reused the Group element, but that felt wrong.
2023-04-16 17:01:11 +00:00
<label title="{{.FirstOption.Description }}">
<input type="radio" name="{{ .Name }}" value="{{ .FirstOption.Value }}"
{{ if eq .Selected .FirstOption.Value }}checked{{ end }}>
{{ .FirstOption.Label }}
</label>
<label title="{{ .SecondOption.Description }}">
<input type="radio" name="{{ .Name }}" value="{{ .SecondOption.Value }}"
{{ if eq .Selected .SecondOption.Value }}checked{{ end }}>
{{ .SecondOption.Label }}
</label>
Replace use of <select> for tags “and” and “or” with checkboxes I realized that using a select for just two, short, options is overkill: the select and its options use a lot more real state than the two radios, which can have tooltips (not yet, though). Since i am going to replace this field with a custom element that has a toggle-like aspect, i already added the is="numerus-toggle" attribute and use it for stying the non-JavaScript field.
2023-04-15 02:05:59 +00:00
</fieldset>
{{- end }}