Честно говоря просто для внутренней структуризации данных городить такой огород из всяких анонимных конструкторов и структур очень напрягает. Сравните, когда этого делать не хочется, то скрепя внутренней гордостью очередной раз чертыхаешься про себя и вводишь какой-то суффикс или префикс. И то и то выглядит криво. Вот пусть бы компилятор сам делал эти «анонимные» классы и структуры. Это ему надо, не мне. (Простите, это вопрос скорее риторический, я не в упрёк вам это говорю)
И что же оказалось в этой пресловутой парадигме не так? А то, что она просто НЕ НУЖНА!!! И это открытие меня поразило до глубины души.
Тоже считаю «почти также». Но только не эта парадигма не нужна, а она нужна, но в другом виде. Лично мне претит ООП с одним уровнем вложенности членов класса. Хочешь два/три уровня как в JSON - добавляй структуру или класс. Вот зачем? Неужели одного класса мало? Не, пусть будет возможность разложения разных уровней абстракции на классы, но пусть бы была возможность многоуровневой абстракции тоже.
От себя добавлю решение обратной задачи. Чтобы открыть из cmd/sh/ps проводник windows в текущей папке нужно набрать "explorer ." (в конце через пробел точка).
Но всё равно полезно знать как делать через диспетчер, т.к. изредка бывает, что проводник сбросился и не перезагрузился. В итоге нет панели с кнопкой «Пуск» и сочетание Win-R не работает. А вот диспетчер задач доступен всегда.
Не совсем шоткат, но бывает при работе в консоли нужно вызвать проводник в текущем каталоге. Обычно мышкой надо выделить путь и закинуть в буфер обмена, потом отдельно вызвать проводник и вставить из буфера обмена текст пути в адресную строку. А можно проще: набрать в консоли команду «explorer .» (в конце точка) и проводник откроется с адресом текущего каталога в консоли.
Валидация одного значения в зависимости от других других
А как при это можно поступить: все участвующие параметры становятся/признаются невалидными или невалидным признаётся только исходный проверяемый параметр? И требуется ли дополнительная валидация участвующих параметров перед такой многопараметровой проверкой?
В этом примере у вас сильная привязка к представлению данных через формы HTML и к TypeScript. У меня есть иерархичные данные с кириллицей в ключах. По поводу иерархии, например, название ключей:
Если данное валидно, то ничего не записано, а если не валидно, то строка с текстом, например: «Параметр (такой-то) должен быть длиннее 1 символа и короче 10. В данный момент его длина: (Len)»
в имени ключа будет присутствовать вся-вся информация, которая доступна
Но мой вопрос был не о тексте сообщения. Вы сказали слово «ключ» в который вы собрались записать «всё-всё». Хотелось бы увидеть пример этого «всего-всего» в ключе?
Всё зависит от рода ошибок. Есть ошибки общего характера - опечатка в числе и очевидно, что сервер это не примет, поэтому нужно не отправлять на сервер запрос, если заранее известно, что значение невалидно. Это экономит ещё лучше. Но есть особенности серверного расчёта, которые клиент не сможет реализовать. Например специфический числовой расчёт. Тут лучше предоставить полную картину, поэтому считать на сервере лучше всё, т.к. есть расчёты, независимые по параметрам.
А про кэш - проблем быть не должно, если он одноразовый - закончилась обработка запроса - кэш забыт.
Думаю, что вы двигаетесь в верном направлении, но считаю, что для повышения производительности стоит кэшировать признак валидации, тогда перед проверкой каждого следующего правила вы будете проверять параметры валидности из кэша, а не вызывать функции валидации повторно. Поэтому вы можете проверять весь диапазон бизнес-правил программы и это будет весьма производительно. Пользователю будет более комфортно работать, если программа сообщает ему все ошибки, а не только первую.
Чисто философски - параметр валидации должен отвечать на один вопрос - «валидна ли вся модель или нет?». Это на случай, если возникнет желание использовать для одних случаев валидации true, а для другого false - везде использовать true для валидных параметров, а false для невалидных параметров.
Погодите-ка! Мне всегда казалось, что тут что-то не сходится! Например - вот начало итерации:
Была одна голова!
Отрубили голову. осталось 0 голов
Выросло две головы. Сейчас 2 головы
Отрубается одна из выросших двух. Осталась одна голова.
На её месте вырастает две. Итого на второй итерации 3 головы.
Итого получаем последовательность:
1;0;2;1;3;2;4;3;5;4;6;5;7;6
По моему вот так должно быть.
Честно говоря просто для внутренней структуризации данных городить такой огород из всяких анонимных конструкторов и структур очень напрягает. Сравните, когда этого делать не хочется, то скрепя внутренней гордостью очередной раз чертыхаешься про себя и вводишь какой-то суффикс или префикс. И то и то выглядит криво. Вот пусть бы компилятор сам делал эти «анонимные» классы и структуры. Это ему надо, не мне. (Простите, это вопрос скорее риторический, я не в упрёк вам это говорю)
Тоже считаю «почти также». Но только не эта парадигма не нужна, а она нужна, но в другом виде. Лично мне претит ООП с одним уровнем вложенности членов класса. Хочешь два/три уровня как в JSON - добавляй структуру или класс. Вот зачем? Неужели одного класса мало? Не, пусть будет возможность разложения разных уровней абстракции на классы, но пусть бы была возможность многоуровневой абстракции тоже.
Погоди. Иконки подвинуть важнее:
Если проблемы будут решаться сами собой, то граждане поймут, что такое государство им не нужно.
В современном мире, пролетарские идеи "отнять и поделить" не в почёте.
Плюс в карму этому господину!
От себя добавлю решение обратной задачи. Чтобы открыть из cmd/sh/ps проводник windows в текущей папке нужно набрать "explorer ." (в конце через пробел точка).
Простите, а с какими "функция" у него были проблемы?
Ну, товарищи! Можно проявить немного больше уважения к читателям и вычитывать автоматические переводы?
Шёл 2024 год...
del
Но всё равно полезно знать как делать через диспетчер, т.к. изредка бывает, что проводник сбросился и не перезагрузился. В итоге нет панели с кнопкой «Пуск» и сочетание Win-R не работает. А вот диспетчер задач доступен всегда.
Не совсем шоткат, но бывает при работе в консоли нужно вызвать проводник в текущем каталоге. Обычно мышкой надо выделить путь и закинуть в буфер обмена, потом отдельно вызвать проводник и вставить из буфера обмена текст пути в адресную строку. А можно проще: набрать в консоли команду «explorer .» (в конце точка) и проводник откроется с адресом текущего каталога в консоли.
А как при это можно поступить: все участвующие параметры становятся/признаются невалидными или невалидным признаётся только исходный проверяемый параметр? И требуется ли дополнительная валидация участвующих параметров перед такой многопараметровой проверкой?
В этом примере у вас сильная привязка к представлению данных через формы HTML и к TypeScript. У меня есть иерархичные данные с кириллицей в ключах. По поводу иерархии, например, название ключей:
Это, чтобы не вводить частности, если это описание какой-то детали.
Я пытаюсь понять границы применимости вашей библиотеки. (По поводу кириллицы и иерархии сразу встречный ответ - вот, что дали)
Если данное валидно, то ничего не записано, а если не валидно, то строка с текстом, например: «Параметр (такой-то) должен быть длиннее 1 символа и короче 10. В данный момент его длина: (Len)»
Но мой вопрос был не о тексте сообщения. Вы сказали слово «ключ» в который вы собрались записать «всё-всё». Хотелось бы увидеть пример этого «всего-всего» в ключе?
Тот момент, когда работающий легаси восхищает. )))
Можно попросить вас привести пример? Я не понял, как это может выглядеть.
А так в целом выглядит неплохо.
Всё зависит от рода ошибок. Есть ошибки общего характера - опечатка в числе и очевидно, что сервер это не примет, поэтому нужно не отправлять на сервер запрос, если заранее известно, что значение невалидно. Это экономит ещё лучше. Но есть особенности серверного расчёта, которые клиент не сможет реализовать. Например специфический числовой расчёт. Тут лучше предоставить полную картину, поэтому считать на сервере лучше всё, т.к. есть расчёты, независимые по параметрам.
А про кэш - проблем быть не должно, если он одноразовый - закончилась обработка запроса - кэш забыт.
Думаю, что вы двигаетесь в верном направлении, но считаю, что для повышения производительности стоит кэшировать признак валидации, тогда перед проверкой каждого следующего правила вы будете проверять параметры валидности из кэша, а не вызывать функции валидации повторно. Поэтому вы можете проверять весь диапазон бизнес-правил программы и это будет весьма производительно. Пользователю будет более комфортно работать, если программа сообщает ему все ошибки, а не только первую.
Чисто философски - параметр валидации должен отвечать на один вопрос - «валидна ли вся модель или нет?». Это на случай, если возникнет желание использовать для одних случаев валидации true, а для другого false - везде использовать true для валидных параметров, а false для невалидных параметров.
Так очень много именно не ISO. Кстати на электронных маркетах нет фильтра по раскладке.