summaryrefslogtreecommitdiff
path: root/view/recipe.go
AgeCommit message (Collapse)Author
2024-03-03view: Provide recipe deletionxengineering
2024-03-03view: Add 'Read' suffix to function namesxengineering
This reflects that these HTTP handler functions implement one of the four CRUD methods create, read update and delete.
2024-03-03view: Replace edit by view parameterxengineering
The old edit URL parameter allowed to select one different HTML template. A more generic approach is to provide a view parameter which allows to use multiple alternative HTML templates for the same data defined by the Go struct. This makes implementing additional pages like a confirm page for recipe deletion easier.
2024-03-03model: Use only string types for modelsxengineering
When a HTML form is converted to JSON by JavaScript using `FormData()`, `Object.fromEntries()` and `JSON.stringify` the data type is always `string`. This does not match the Go struct definitions using multiple types including e.g. `int`. There are several options to solve this conflict: 1. use only strings in Go struct definitions 2. write custom functions to parse string-based JSONs to Go structs 3. implement custom functions in JS to use `number` type if possible Option 3 seems to be a very clean solution. Nevertheless it is limited by the fact that JSON anyway has a way more limited type system than Go. So the types used in Go cannot be used and this would reduce this option to a variant of option 2. Option 2 requires significant effort per struct inside the model package. Every object which is transferred via JSON and serialized into Go structs would require a second struct definition with string types and a conversion function. This does not scale. Thus option 1 seems to be the best fit. The reasons for using types like `int` or `bool` are: - less memory consumption than `string` in most cases - implicit data validation (e.g. enforcing positive numbers with `uint`) - better compatibility with certain APIs which rely on e.g. `int` The first argument is not so relevant in this use case. The amount of required memory is still quite small for servers. Implicit data validation is a good thing but not enough. There should anyway be validation method which has to be called on CRUD methods and JSON deserialization.
2024-02-15view: Add edit view for model.Recipe typexengineering
2024-02-13view: Implement GET handler for model.Recipexengineering