torch
torch copied to clipboard
mojotech
Nullable date field in new/edit view
I have a table that contains a Date field which is optional.
Torch new and edit pages always shows the field as mandatory since it shows the date widget without an option to disable it.
Is it possible to make it optional or do I need to that logic myself in the view?
Currently you'd have to handle this yourself. Either in the front end view template and/or on the back end controller that is parsing the incoming data.
Non-required schema fields are something we could look at supporting via some sort of "optional" mechanism. It would require some thought and discussion as to how this would work for all different input types.
For instance, in your example for a date field, what would your expected interaction be? That the form doesn't submit any data for that field at all? That the form submits null or "zero values" for the field?
Since an optional field would normally translate to a nullable field in the database, I would expect that the form would submit the field with nil, that way the changeset keeps working as expected.
Maybe a good solution in the view part would be to have a check-box before the date field, so if the check-box is selected, the date field is enabled and accepts input, if the check-box is not selected, the date field is grayed out, blocks input and the form returns nil for that field.
There are variants to that though. We can't assume that an "optional" field is nullable. What about schemas that have a field "default" value where null is also a valid value? If Torch were to pass in nil as a value, that could inherently mean something different than "unset". You may intend to say, I'm not providing any value for this field, so use the specified default vs. I'm explicitly saying the value for this field should be a null value.
I think what would need to happen is that we would need a mechanism to disable the optional form fields in question so that they do not get included in the form submission at all.
Oh sorry for the late reply.
To be honest, I don't know what is the best solution since, as you highlighted, there are some variants to the optional field which I didn't consider when I created the issue.
Maybe the current solution of simply handle that manually by the user is good enough?