Opened 11 months ago
Closed 7 months ago
#620 closed баг (fixed)
Сообщение диалога о том что импорт конфига TDM успешен не соответствует действительности.
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | sw | Keywords: | |
| Cc: |
Description
Если функция Импорт конфига TDM не нашла конфига в файле, то сообщает пользователю что Импорт успешен, хотя по факту конфиг не был обнаружен в файле и сообщить нужно об этом
Attachments (1)
Change History (21)
comment:1 by , 11 months ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 11 months ago
Было бы еще лучше, если бы у всех трех видов документов корневые элементы назывались по-разному, но в свое время мне эта мысль в голову не пришла, а теперь уже это менять поздно, так как нарушится обратная совместимость... :(
follow-up: 4 comment:3 by , 7 months ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
В r2314 импортировал на вкладке TDM импортировал вместо конфига TDM конфиг блока и получил сообщение "Настройки успешно импортированы", хотя это не так(обсуждали подобное в #619).
Пользуясь случаем, ещё раз отмечу, что мне как пользователю было бы удобнее, если бы была возможность импортировать конфиг TDM прямо из конфига блока, как это сделано для конфига плат. Т.к. часто имея конфиги целых блоков, мне нужно загружать из них в свой блок только часть - например конфиг платы или конфиг TDM или конфиг Ethernet.
comment:4 by , 7 months ago
by , 7 months ago
| Attachment: | config-ГРС Турушла-14-11-2022.xml added |
|---|
comment:5 by , 7 months ago
Replying to san:
Если функция Импорт конфига TDM не нашла конфига в файле, то сообщает пользователю что Импорт успешен, хотя по факту конфиг не был обнаружен в файле и сообщить нужно об этом
Посмотрел файл, который ты импортировал. Насколько я вижу, он имеет корректный заголовок и корневой элемент <config/>, как того и ожидает выполняющий импорт код. Почему ты считаешь, что конфиг не был обнаружен в файле?
follow-up: 7 comment:6 by , 7 months ago
Я хотел импортировать конфигурацию TDM. Я взял импортировал файл конфига блока в котором конфиг TDM присутствовал в иерархии <config><board> <mapper>.....</mapper></board></config>, интерфейс сообщил мне, что импорт успешен, однако соединения в TDM из <mapper> не появились.
Если импорт не произошёл, то импорт не мог быть успешным)
comment:7 by , 7 months ago
Replying to san:
Я хотел импортировать конфигурацию TDM. Я взял импортировал файл конфига блока в котором конфиг TDM присутствовал в иерархии <config><board> <mapper>.....</mapper></board></config>, интерфейс сообщил мне, что импорт успешен, однако соединения в TDM из <mapper> не появились.
Если импорт не произошёл, то импорт не мог быть успешным)
Ты неверно интерпретируешь произошедшее. Импорт произошел. Так как в импортируемом файле не содержалось конфигурации TDM-маппера (не было элемента <config><mapper/></config>), в TDM-маппер была загружена конфигурация по умолчанию (кажется, это константа во всех каналах, не помню точно).
Ты можешь легко это проверить следующим экспериментом:
- Скоммутируй в TDM-маппере несколько произвольных каналов.
- Выполни импорт, как ты описал выше.
- Перезагрузи страницу и снова зайди в TDM-маппер.
Если ты увидишь, что сделанные в п. 1 коммутации пропали (а я думаю, что именно это ты и увидишь) - значит импорт произошел. Если бы импорт не был выполнен, сделанные тобой коммутации в TDM-маппере остались бы нетронутыми.
follow-up: 9 comment:8 by , 7 months ago
Но импортируя файл конфига содержащий корректный конфиг TDM пользователь явно не расчитывал вместо него получить пустую таблицу. Это совсем не дружелюбное поведение)
В идеальном, на мой пользовательский взгляд, случае должен был быть загружен конфиг TDM из платы SW-01 <config><board> <mapper>.....</mapper></board></config>. В неидеальном варианте, хотя бы должно быть сообщение об ошибке.
comment:9 by , 7 months ago
| Resolution: | → готово |
|---|---|
| Status: | reopened → closed |
Replying to san:
Но импортируя файл конфига содержащий корректный конфиг TDM пользователь явно не расчитывал вместо него получить пустую таблицу. Это совсем не дружелюбное поведение)
Вынужден напомнить, что в рассматриваемой ситуации импортируется файл, вообще для этого не предназначенный. Да, я признаю, что принял неудачное решение (точнее, просто не подумал о возможности подобной ситуации), приняв для экспортированных конфигураций тот же формат, что и для полной конфигурации блока (у обоих корневой элемент называется <config/>). Как результат - нет возможности отличить конфигурацию блока от экспортированной конфигурации TDM. И изменить это я тоже не могу, так как в противном случае я нарушу совместимость - перестанут импортироваться файлы, экспортированные до этого изменения...
Приведу другой пример. Представь себе такую ситуацию: пользователь экспортировал настройки TDM из блока и сохранил их в файл a.xml. Потом он экспортировал настрофки TDM из другого блока, где они совсем другие, и сохранил их в файл b.xml. Затем он хочет в третий блок импортировать настройки TDM первого блока, но по ошибке вместо файла a.xml импортирует файл b.xml. Что будет в результате импорта? Да то же самое - пользователь получит настройки, которых явно не рассчитывал получить! Можно ли программно обнаружить ошибку в данном случае?
Резюмирую: в описанном случае имела место ошибка пользователя, импортировавшего не тот файл. Да, в отдельных частных случаях такую ошибку можно было бы выявить, но из-за того, что я сразу такого варианта не предусмотрел, момент упущен. Я считаю, что на данный момент (с учетом коммита r2295, сделанного по этому тикету) сделаны все возможные проверки для выявления попытки импорта ошибочного файла - например будет выдана ошибка при попытке импорта файла, не содержащего XML документ (например картинки JPEG) или содержащего XML документ, но с отличным от <config/> корневым элементом (например файл с диаграммой dia)...
В идеальном, на мой пользовательский взгляд, случае должен был быть загружен конфиг TDM из платы SW-01 <config><board> <mapper>.....</mapper></board></config>.
Это напомнило мне пользователя, о котором ты мне когда-то рассказывал - он не нашел в веб-интерфейсе кнопку, которую его попросили нажать, поэтому вместо нее нажал другую (первую попавшуюся). Мне такое поведение, мягко говоря, не кажется разумным и правильным. :)
В неидеальном варианте, хотя бы должно быть сообщение об ошибке.
См. резюме выше. Я считаю, что на данный момент сделаны все разумные проверки для выявления ошибки. Любую ошибку такого рода выявить невозможно в принципе - см. приведенный мной пример выше.
follow-up: 11 comment:10 by , 7 months ago
Мне такое поведение, мягко говоря, не кажется разумным и правильным
Ну тут сравнение натянутое. В моём примере в файле пользователя есть тот самый конфиг, который пользователь хочет импортировать. Просто он находится на другой ступени иерархии.
И раз из такого файла конфига всё-равно импортируется "что попало" (пустой TDM), мне кажется тут мы могли бы быть более дружелюбны к пользователю и импортировать более подходящее "что попало" (конфиг TDM SW-01)
comment:11 by , 7 months ago
Replying to san:
Мне такое поведение, мягко говоря, не кажется разумным и правильным
Ну тут сравнение натянутое. В моём примере в файле пользователя есть тот самый конфиг, который пользователь хочет импортировать. Просто он находится на другой ступени иерархии.
Откуда SW-01 может быть уверена, что лежащий в "ненадлежащем" месте элемент <mapper/> содержит именно тот самый конфиг, который пользователь и хочет применить? Скорее уж наличие элемента в неожиданном месте могло бы говорить о том, что пользователь пытается импортировать ошибочный файл. Гипотетически, можно было бы на основании этого выдать ошибку. Но с другой стороны, наличие "неожиданного" элемента не обязательно говорит об ошибке, а может быть следствием того, что ПО SW-01, импортирующего файл, просто старее ПО, которое этот файл экспортировало, поэтому некоторые элементы, которые были записаны в файл, импортирующий код просто не знает. Язык XML как раз хорош своей гибкостью, позволяя пропускать (игнорировать) неизвестные ему элементы, чем обеспечивается обратная совместимость. Аналогично, отсутствующие в файле элементы не являются ошибкой для обеспечения прямой совместимости - то есть возможности импортировать файл, экспортированный ПО более старых версий, которые еще "не знали" о появившихся позже конфигурационных элементах...
И раз из такого файла конфига всё-равно импортируется "что попало" (пустой TDM),
И опять тот же вопрос: Опять же, откуда SW-01 может знать, что импортируется "что попало"? Откуда она может знать, что пользователь на самом деде хотел импортировать вовсе не то, что записано в переданном им файле? Ты сейчас говоришь "что попало" и "тот самый конфиг, который пользователь хочет импортировать" только потому, что пользователь - это ты, и ты знаешь, что ты хотел получить на самом деле. А как это может знать плата SW-01? )
мне кажется тут мы могли бы быть более дружелюбны к пользователю и импортировать более подходящее "что попало" (конфиг TDM SW-01)
То есть ты все-таки предлагаешь, чтобы SW-01, не найдя элемент в положенном месте, искала любой другой элемент с тем же именем по всему документу? Пожалуй, я все-таки с таким вариантом согласиться не могу...
comment:12 by , 7 months ago
Сейчас у меня возникла мысль, что можно было бы попробовать выдавать пользователю предупреждение о том, что какие-то элементы не были найдены, и использованы значения по умолчанию. Это бы навело его на мысль о том, что он импортировал не тот файл...
comment:13 by , 7 months ago
Пока я шел домой, у меня возникла еще одна идея (в чем-то развитие предыдущего комментария), записываю на всякий случай чтобы не забыть. :)
Можно в процессе импорта в каким-то образом посчитать, сколько известных (ожидаемых) элементов присутствовали в импортируемом файле (см. предыдущий комментарий), а также сколько в документе встретилось неизвестных (неожиданных) элементов, которые были проигнорированы. После этого можно вычислить некий показатель, назовем его условно "степень успешности", на основании которого делать выводы и давать пользователю соответствующие предупреждения. Например если:
- прочитаны и применены данные из 10 известных элементов;
- 2 элемента не были найдены, и были применены значения по умолчанию;
- обнаружен и проигнорирован 1 неизвестный элемент.
то можно считать, что импорт успешен. Если же, например, из 12 ожидаемых элементов конфигурации найдены только 2, и кроме этого обнаружено 15 неизвестных элементов, можно предположить, что пользователь ошибся, импортировав не тот файл.
Есть вопросы, как быть с элементами, число (и вообще наличие) которых переменно, например элементы <channel/> и/или <user/> в конфиге платы VE-01 - их могут быть сотни, а может не быть ни одного...
follow-up: 15 comment:14 by , 7 months ago
только потому, что пользователь - это ты, и ты знаешь, что ты хотел получить на самом деле. А как это может знать плата SW-01? )
Ну да, я тут от имени пользователя и говорю. Я понимаю что плата SW-01 о том что хочет сделать пользователь не знает. Но мы как разработчики ведь можем "предсказать" некоторые, наиболее распространённые, сценарии. Попытка импорта чего-нибудь отдельного из файла конфига блока, с точки зрения пользователя, выглядит вполне разумно - в файле же есть конфиг TDM, например, и с точки зрения пользователя он там один, так почему бы не импортировать его в блок.
То есть ты все-таки предлагаешь, чтобы SW-01, не найдя элемент в положенном месте, искала любой другой элемент с тем же именем по всему документу?
Не совсем. Я предлагаю немного подстроиться под определённые сценарии действий пользователя. Т.е. не найдя элемент в положенном месте искать элемент в другом, определённом, месте. Например, по сценарию "пользователь загружает конфиг TDM из конфига блока" SW-01, не найдя <config><mapper/></config>, должна будет проверить нет ли в файле <config><board></mapper></board></config> и если есть - загрузит его.
comment:15 by , 7 months ago
Replying to san:
То есть ты все-таки предлагаешь, чтобы SW-01, не найдя элемент в положенном месте, искала любой другой элемент с тем же именем по всему документу?
Не совсем. Я предлагаю немного подстроиться под определённые сценарии действий пользователя. Т.е. не найдя элемент в положенном месте искать элемент в другом, определённом, месте.
В каком?
comment:17 by , 7 months ago
Replying to san:
В каком?
Внутри <config><board type="SW-01" slot="9">
Теперь я, кажется понял твою мысль. Ты предлагаешь при отсутствии элемента в "основном" месте (где он создается при экспорте) пробовать найти его в одном конкретном "аварийном" месте (в настройках SW-01 полного конфига)... Это уже лучше, чем первый попавшийся элемент в документе. Но все равно остаются вопросы (например как быть с импортом конфига платы VE-01? Их может быть несколько в конфиге блока)...
Создай по этому вопросу, пожалуйста, новый тикет (это твое предложение уже довольно далеко от темы сообщения об успешности/неуспешности импорта).
comment:19 by , 7 months ago
| Resolution: | готово |
|---|---|
| Status: | closed → reopened |
Я внимательно посмотрел экспортированные файлы и обнаружил, что в них отсутствует элемент <created/>! Таким образом, эти файлы, оказывается, легко и безопасно можно отличить от файла конфигурации блока. Думаю, что это решает нашу проблему.
In 2295/sw: