Issue with dependent() and inline editing
Issue with dependent() and inline editing
Hello there,
I am wondering if there is a way to debug the dependent() field function when using the cascading lists? The problem that I am having is that when the table and editor are initialized, the first request to the list PHP includes a value that has not yet been set yet -- but most interestingly is including a value that cannot exist.
Or, if no option to debug, is there a bug with the dependent() cascading lists where it should include a list of everything, but instead is already filtering for the dependent's value)?
The reason this came up is because when doing inline edits -- prior to having any Editor windows (create or edit) open -- the dependent fields' value is being erased because the list is wrong for that particular row.
Hopefully that makes some sense. Any help or insight would be greatly appreciated.
Answers
Inline editing and dependent do not play nicely together unless you use multi-cell inline editing, like here.
With inline editing, normally you just have a single cell editable, but if you are updating the options of another cell that isn't editable and does need to be edited as a result, then there is a conflict.
It should send the default value? Perhaps you can give me a link to the page you are working on so I can take a look?
Allan
Hello Allan, thanks for the quick reply!
Yes, I noticed some funny business between the dependent fields as well during normal Editor edits ... We had some hidden fields that we ended up having to change to text fields and then hide after initializing the Editor instance in order to get the proper list values for its related fields. That isn't really much of an issue, though.
But your feedback did help me identify the problem!
After a bit more chasing the white rabbit down his hole, I realized that this value is coming from the first option in the child field's dependent select list, as it is a required field with the placeholder disabled. Switching this to allow a placeholder resolves the problem.
In cases like this, where we have a select field and its dependent child field, do you think that the default Editor functionality should consider (prior to and after any edit) dependent fields to not have a value, instead of having the first value in the select list, regardless whether or not there is a placeholder?
It makes sense to have that value be set at the earliest possible event during an edit, and then pull the related data for the select list that would include the previously set value.
I did try to set that field during the initEdit event, but it did not give the results I was hoping for and repopulate the dependent's select list with the right values.
Anyhow, I do have the workaround in place for the time being. But please let me know your thoughts on that behavior for select lists with no placeholder that also function as a child field's dependent value, if that is essentially the best approach for the Editor library or if it could be adjusted slightly to account for this possibility.
Much thanks for your help and insight, Allan. Cheers!
I absolutely see that point. What should be happening is that Editor shouldn't allow the submission until the list of options has been loaded. But by that time it would have picked up the first value in the existing list. It doesn't empty the list out.
I'll need to have a bit of a think about that, I suspect it will have other implications that I haven't thought of yet.
Great that you've got a workaronud for now though - nice one!
Allan (pondering...)
Great, thanks for your help, Allan. Ponder away!
I will say that after the initial edit, all subsequent edits do behave as expected. That might have something to do with my code having re-populated the child field with all possible options of its dependent field, however.
Thanks!