New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(forms): Convert default values when question type change #17073
base: main
Are you sure you want to change the base?
feat(forms): Convert default values when question type change #17073
Conversation
I am not sure if this should be done on the server. The What do you think @cedric-anne ? |
I am not sure that this kind of logic is even required. Maybe it can automatically be done by using strict input types. For instance:
Switching from on type to another will probably natively invalidate/discard the value if it is not compatible. |
This logic follows on from @orthagh's request in the PR, which integrates actors #16791 (review). This logic could also be relevant when switching between checkbox and radio questions. In this PR, a first example has been made with short answers, which seem a little less relevant than actors or selectables. |
Having a unique PHP endpoint is probably easier to handle. Indeed, I am afraid that some cases may not be handled on JS side only, and would require to create specific ajax endpoints. It is preferable to have a unique ajax endpoint that forwards to a PHP logic normalized by an interface instead of having multiple specific ajax endpoints added later in GLPI or in plugins. |
be937b5
to
1233b7b
Compare
I am still not sold on the backend part. Each question could define two javascript method: 1) 2) I think this way it can be handled with 0 backend interference. What do you think @cedric-anne ? |
OK to do it on JS side, using JS callbacks defined by the QuestionType PHP classes, and defined by the interface. A way to do it could be to have a return <<<JS
{
"extractDefaultValue": function (input_name) { return null; },
"convertDefaultValue": function (input_name, value) { return value; },
...
}
JS; and it would be registered on form initialization this way {% for question_type in question types %}
glpi_form_editor_controller.registerQuestionTypeOptions('{{ get_class(question_type)|e('js') }}, {{ question_type.getFormEditorJsOptions() }})
{% endfor %} It is probably the most flexible way to permit to each question type to register some specific behaviours on Js side, but it would require to be as much documented as possible. |
For GLPI native question types, the JS options may probably be placed in some dedicated JS files and the PHP code may be something like that (to be tested): public function getFormEditorJsOptions(): string
{
return 'await import("/path/to/question/defaults.js");';
} |
Added a mechanism for converting default values when changing question types.