Для зависимых полей приходится писать кастомные классы-валидаторы
Слишком уж сложно для данного случая. (В вопросе не было уточнения, но в приложении нет MVC-модели - это API-сервис).
Требуется просто проверка и выставление кода ошибки. Вопрос в скорости "регистрации" нового кода ошибки и в его уникальности. Номер должен упоминаться в коде только один раз. В принципе я сделал проверку, чтобы при присвоении в runtime проверялось, что такого числа ещё не было присвоено ошибке, но это сильно не надёжно, поэтому и хотелось бы сделать какую-то "визульную" проверку уникальности при наборе кода. Предполагается, что я буду только увеличивать номер ошибки и Visual Studio должна мне подсказывать, что кода, который мне нужен - нет. Тут-то я его и создам. Вопрос - минимум усилий!
Это-то всё есть. Однако моя программа не должна останавливаться на первой ошибке, поэтому исключения не подходят. Сначала программа "коллекционирует" все ошибки, которые только могут встретиться в параметрах. От неправильного написания значения параметра, до несовместимости, поэтому мне не нужно бросать исключение, если пользователь вместо числа написал свою фамилию. Я ему в конце проверки выкатываю полный список что неправильно введено. Расчёт ещё не производится.
P.S.
Если я в программе буду писать не номер ошибки, а создавать исключение, то ничего по сути не меняется - вместо чисел, я буду вынужден хранить объекты исключений, т.к. бросать их мне не нужно. Слишком сложно для поддержки. Каждый раз нужно возвращаться в Enum и определять новый код, писать руками "Error23 = 23" в то время как (обратите внимание) номер кода ошибки уже содержится в названии Error23. Нужно сократить время, которое я затрачиваю, чтобы "зарегистрировать" ошибку в коде. если выражаться не техническим языком, то "хочу, чтобы ошибка по номеру создавалась автоматически". Понимаю, что желание странное, но вот хочу )))
По сути очень хороший вариант, но очень сложно поддерживать. В каждой формуле нужно помнить названия параметров. Но не смотря на это я размышляю именно в этом направлении и всё больше склоняюсь к тому, что нужно сделать парсер, например, на основе antlr. Там главный цикл обработки выражения (visitor или listener) как раз и можно запускать в нескольких режимах, в зависимости от потребности - либо считать, либо "собирать" имена переменных и заменять их на названия, понятные пользователю, либо заменять их на значения и возвращать само выражение.
Я не сказал об одной тонкости задачи - переменные, типа D_SVAYA уже находятся в dictionary со значением, описанием и др. свойствами, поэтому извлечь необходимые величины для замены - не проблема.
Спасибо, но eval не подходит, т.к. решение не управляемое. Результат на выходе не всегда только числовой результат. Из выражения может потребоваться получить и расшифровку параметров и подстановку числовых значений (чтобы пользователь мог проверить сами числа) и, конечно, сам результат. Может быть в будущем, если формулы будут позаковыристей, то и вид типа equation.
Вопрос не в распаковке архива. 7-zip это легко делает. Нет ли какой-то хитрости с самими файлами при помещении их в WAR, чтобы не пришлось с чем-то столкнуться после извлечения?
Артур Нуруллин, Пробовал. Но если dotnet обнаруживает, что если требуется загрузить подписанную сборку, то даже до срабатывания события AssemblyLoad дело не доходит. В документации написано, что подписанные сборки могут загружать только подписанные сборки и при этом не должны загружать не подписанные, но при этом нигде не было написано, что запрещено вызывать это событие, если подписанная сборка не найдена среди файлов на диске.
Так же в документации написано, что запрет загрузки только подписанных сборок можно отключить через реестр, но этот вариант не подходит.
sim3x, Спасибо за подсказку. Только что сумел перевести проект на модули через npm, но возникла проблема загрузки совместимых компонентов.
Позвольте ещё задать вопрос?
Когда я скачивал модули через bower, то он добросовестно проверял совместимость компонентов и любезно спрашивал, что меня устроит:
А так же докачивал недостающие компоненты сам и их не надо было прописывать в bower.json.
npm же тупо сливает то, что записано в package.json и не спрашивает ничего. Только то, что есть:
Не очень удобно. Пришлось искать зависимости самому и выяснять точное название с номером версии и докачивать в таком виде.
Например, в bower мне не приходилось указывать компонент select2
Есть ли возможность как-то заставить npm проверять совместимость между компонентами или придётся это всё делать вручную?
sim3x, В смысле для меня новые. Ни разу не пробовал. Кроме install и search больше ничем не пользовался. Был свой набор компонентов, которые не сильно требовалось менять. Не подскажите, в каком менеджере есть та пара функций? (Поискать и поставить компонент). Не затруднит на память вспомнить эти команды, если не трудно?
Домой приеду, почитаю.
zlodiak, попробуйте проверить, а какие настройки прокси появляются в вашем браузере после того, как вы включаете проксирование через fiddler (я никогда не запускал ещё fiddler в linux, но как я понял, он там ещё в стадии beta)?
Ну, так чтобы проверить, что браузер действительно перенаправляет запросы в fiddler.
zlodiak, точно. Допишите в строку Настроек “protocols”, после tls1.0 ещё «;tls1.1;tls1.2;» (для вызова диалогового окна щёлкните мышкой на строку). Повторите запрос?
Требуется просто проверка и выставление кода ошибки. Вопрос в скорости "регистрации" нового кода ошибки и в его уникальности. Номер должен упоминаться в коде только один раз. В принципе я сделал проверку, чтобы при присвоении в runtime проверялось, что такого числа ещё не было присвоено ошибке, но это сильно не надёжно, поэтому и хотелось бы сделать какую-то "визульную" проверку уникальности при наборе кода. Предполагается, что я буду только увеличивать номер ошибки и Visual Studio должна мне подсказывать, что кода, который мне нужен - нет. Тут-то я его и создам. Вопрос - минимум усилий!