camper/pkg/form/input.go

87 lines
1.5 KiB
Go
Raw Normal View History

/*
* SPDX-FileCopyrightText: 2023 jordi fita mas <jfita@peritasoft.com>
* SPDX-License-Identifier: AGPL-3.0-only
*/
package form
import (
"database/sql/driver"
"net/http"
"strconv"
"strings"
2023-12-22 01:23:18 +00:00
"golang.org/x/text/language"
"dev.tandem.ws/tandem/camper/pkg/database"
"dev.tandem.ws/tandem/camper/pkg/locale"
)
type Input struct {
Name string
Val string
Error error
}
func (input *Input) setError(err error) {
input.Error = err
}
func (input *Input) FillValue(r *http.Request) {
input.Val = strings.TrimSpace(r.FormValue(input.Name))
}
func (input *Input) Value() (driver.Value, error) {
return input.Val, nil
}
Make home page’s carousel manageable via the database I debated with myself whether to create the home_carousel relation or rather if it would be better to have a single carousel relation for all pages. However, i thought that it would be actually harder to maintain a single relation because i would need an additional column to tell one carrousel from another, and what would that column be? An enum? A foreign key to another relation? home_carousel carries no such issues. I was starting to duplicate logic all over the packages, such as the way to encode media paths or “localization” (l10n) input fields. Therefore, i refactorized them. In the case of media path, i added a function that accepts rows of media, because always need the same columns from the row, and it was yet another repetition if i needed to pass them all the time. Plus, these kind of functions can be called as `table.function`, that make them look like columns from the table; if PostgreSQL implemented virtual generated columns, i would have used that instead. I am not sure whether that media_path function can be immutable. An immutable function is “guaranteed to return the same results given the same arguments forever”, which would be true if the inputs where the hash and the original_filename columns, instead of the whole rows, but i left it as static because i did not know whether PostgreSQL interprets the “same row but with different values” as a different input. That is, whether PostgreSQL’s concept of row is the actual tuple or the space that has a rowid, irrespective of contents; in the latter case, the function can not be immutable. Just to be in the safe side, i left it stable. The home page was starting to grow a bit too much inside the app package, new that it has its own admin handler, and moved it all to a separate package.
2023-09-14 23:05:38 +00:00
func (input *Input) Int() int {
i, err := strconv.Atoi(input.Val)
if err != nil {
panic(err)
}
return i
}
Make home page’s carousel manageable via the database I debated with myself whether to create the home_carousel relation or rather if it would be better to have a single carousel relation for all pages. However, i thought that it would be actually harder to maintain a single relation because i would need an additional column to tell one carrousel from another, and what would that column be? An enum? A foreign key to another relation? home_carousel carries no such issues. I was starting to duplicate logic all over the packages, such as the way to encode media paths or “localization” (l10n) input fields. Therefore, i refactorized them. In the case of media path, i added a function that accepts rows of media, because always need the same columns from the row, and it was yet another repetition if i needed to pass them all the time. Plus, these kind of functions can be called as `table.function`, that make them look like columns from the table; if PostgreSQL implemented virtual generated columns, i would have used that instead. I am not sure whether that media_path function can be immutable. An immutable function is “guaranteed to return the same results given the same arguments forever”, which would be true if the inputs where the hash and the original_filename columns, instead of the whole rows, but i left it as static because i did not know whether PostgreSQL interprets the “same row but with different values” as a different input. That is, whether PostgreSQL’s concept of row is the actual tuple or the space that has a rowid, irrespective of contents; in the latter case, the function can not be immutable. Just to be in the safe side, i left it stable. The home page was starting to grow a bit too much inside the app package, new that it has its own admin handler, and moved it all to a separate package.
2023-09-14 23:05:38 +00:00
func (input *Input) L10nInput() *L10nInput {
return &L10nInput{
Input: Input{
Name: input.Name,
},
Source: input.Val,
}
}
type L10nInput struct {
Input
Source string
}
type I18nInput map[string]*Input
func NewI18nInput(locales locale.Locales, name string) I18nInput {
input := make(I18nInput)
for lang := range locales {
input[lang.String()] = &Input{
Name: name + "." + lang.String(),
}
}
return input
}
func (input I18nInput) FillValue(r *http.Request) {
for _, inner := range input {
inner.FillValue(r)
}
}
2023-12-22 01:23:18 +00:00
func (input I18nInput) FillArray(array database.RecordArray) error {
for _, el := range array.Elements {
tag, err := language.Parse(el.Fields[0].Get().(string))
if err != nil {
return err
}
input[tag.String()].Val = el.Fields[1].Get().(string)
}
return nil
}