Это я как бы уже знаю :) Вопрос был касаемо определенного набора файлов, например, по расширению. Но, как я уже понял, так нельзя. Можно только на набор файлов в каталоге.
сергей кузьмин, точнее, один сервис. А поскольку приложение монолитное и активность одного элемента не имеет смысла без другого, всю эту связку, наверное, можно считать одним сервисом. А может быть, и нельзя. В общем, философия - штука прогибчивая, интересно, как такое на практике себя ведет.
Adamos, видимо, да. Просто внутри есть скрипты, которые желательно оставить исполняемыми, но их в целом немного и потом можно проставить права на каждый индивидуально.
Lynn «Кофеман», ну там ни то, ни другое, а совсем третье: эти файлы перенесены с диска ntfs, и при этом являются содержимым тома docker-контейнера. Если в том же томе создать свой JSON-файл, он будет открываться сразу, без предложения выполнить.
Блин. В который раз на это попадаюсь, стыдно) Спасибо!
Да ну? А как вы это проверяли? По внешнему виду компонента?
1) Открываем VUE dev tools, находим нужный компонент, раскрываем data.
2) Кликаем. Молчок.
3) Закрываем диалог, и наблюдаем, как в растворяющемся благодаря анимации блоке чекбоксы сами собой отмечаются и data в dev tools чудесным образом прописывается.
Только надо иметь в виду - если, как написал автор вопроса, JOIN orders уже используется для получения других данных - списка заказов пользователя, например, то этот список у пользователя "схлопнется" в одну позицию.
Akina, прямо таки вообще-вообще?
Поскольку речь шла об условных данных и неуказанных JOIN'ах по другим критериям, я предположил, что запросу в посте мешают выполняться ошибки "ambiguous column name". Других видимых проблем в исходном запросе нет.
Причина в том, что я допустил в пути опечатку - mages вместо images, из-за этого получал This dependency was not found, когда, как положено, размещал картинку в @/assets/screens/images/. Элементарный тупизм, короче :))))
Но по вашей ссылке нашел то, на что раньше не обращал внимания. Получается, всё равно помогли, спасибо!
WbICHA, ок, убедительно, тут вы правы :) Но меня перечисленные детали обычно не напрягают, поэтому стараюсь пользоваться if-ами, т.к. код мутирует, блоки увеличиваются, а if-ы не надо перестраивать в другие конструкции для расширения условий.
WbICHA, свитч НЕ лучше. К нему вообще сильно привыкать не рекомендуется, чтобы не тащить потом в большие блоки кода и не превращать их в лапшу.
В данном случае блоки однострочные, читаемость кода будет одинаковой, что switch, что if, поэтому не суть важно. Замена if на switch здесь - не рефакторинг, а вкусовщина.
