Total Commander :: [wlx] XML Review - просмотр XML и JSON файлов

[wlx] XML Review - просмотр XML и JSON файлов

through

[^/[Print]\]
Goto page 1, 2, 3 Next :| |:
Total Commander -> Плагины Total Commander

#1: [wlx] XML Review - просмотр XML и JSON файлов Author: Destiny,

Posted: Tue Mar 15, 2022 18:13
—
XML Review 3.2.1

Плагин для просмотра XML и JSON файлов. Три режима просмотра:

Расширения по умолчанию xml, xsd, xsl, xslt, wsdl, json.

Автор: olegvsk
https://olegvsk.synology.me

Скрин
Скачать по прямой ссылке: https://olegvsk.synology.me/XMLReview/xmlreview.zip

Это тема для обсуждения работы плагина.

Я НЕ автор! его сайт: https://olegvsk.synology.me/XMLReview/xmlreview.htm
Его почта: olegvsk@outlook.com

Last edited by Destiny on Thu Mar 17, 2022 13:43; edited 1 time in total

#2: Author: olegvsk,

Posted: Tue Mar 15, 2022 22:13
—
Благодарю за внимание. Я автор, с удовольствием отвечу на вопросы/предложения/критику.

#3: Author: Destiny,

Posted: Thu Mar 17, 2022 13:09
—

olegvsk wrote:

Я автор

Урра!!! День добрый!
Собсно по этому - но более по второму вашему продукту - Cert View есть вопросы/предложения.
В этой теме, значится, пройдемся то по этому продукту...
В теме про Cert View(https://forum.wincmd.ru/viewtopic.php?p=135008) напишу про неё.

XML Review - выполняет валидацию. Что по идее хорошо! НО! часто есть нужда в просмотре
ЧАСТИЧНЫХ xml! Т.е. файлов, где нет одного элемента верхнего уровня. А есть лишь список
подэлементов. Ваш плагин в этом случае отображает лишь первого представителя из этого
списка и всё. Потому как есть ошибка валидации КАК БЫ ожидаемого настоящего XML дерева.
НО в этом конкретном случае было бы очень полезно иметь некую псевдозаглушку, которую
можно даже настраивать в диалоге настроек, работающую как КОРНЕВОЙ фиктивный первый
элемент. Так мы бы хоть и искусственно, но вышли бы из сложного положения. К примеру,
по умолчанию, пусть это будет тег <ROOT_TAG>....</ROOT_TAG>
И тогда, если встречается ошибка парсинга
Position ....: В документах XML допускается только один элемент верхнего уровня.
то, если в настройках включено - обкладывать все содержимое файла тегом ROOT_TAG - значит
эта ошибка была бы нивелирована! И тогда все содержимое файла по сути стало бы однозначно
валидным, т.к. оно будет обложено одним тегом верхнего уровня, что и требуется по правилам Wink

При генерации XPath для повторяющихся тегов вы не вставляете
адресный идентификатор [i], где i - это число по порядку в повторе.

Code:

<LIST_OF_PERSONS>
<DATA>
<NAME>...</NAME>
<ID>...</ID>
<PASSPORT>
<SERIJA>...</SERIJA>
<NOMER>...</NOMER>
</PASSPORT>
</DATA>
<DATA>
<NAME>...</NAME>
<ID>...</ID>
<PASSPORT>
<SERIJA>...</SERIJA>
<NOMER>...</NOMER>
</PASSPORT>
</DATA>
<DATA>
<NAME>...</NAME>
<ID>...</ID>
<PASSPORT>
<SERIJA>...</SERIJA>
<NOMER>...</NOMER>
</PASSPORT>
</DATA>
</LIST_OF_PERSONS>

И вот для второй ДАТЫ для тега "Серия Паспорта", к примеру, XPath должен быть вида:
/LIST_OF_PERSONS/DATA[2]/PASSPORT/SERIJA

А у вас будет написано просто /LIST_OF_PERSONS/DATA/PASSPORT/SERIJA

вот сторонний ресурс есть, где можно проверить мои слова:
https://xmltoolbox.appspot.com/xpath_generator.html

Тоже и для JSON файла. Самой валидации теперь вроде как нет в меню, т.е. саму
ошибку вы не пишите, НО и парсинг файла далее не производите, если встретили её.
К примеру, в некоторых JSON файлах после элементов пишутся комментарии.

Code:

"Common": {
"ButtonRadius": 0,
"WindowBorderRadius": 3, // 0 - None, 1 - Top, 2 - Both, 3 - Small
"ClientBackColor": "1d8abd",
"GroupBoxColor": "1586bb", // Required
"PaintClassicFocus": true
}

стандартом файла они вроде не предусмотрены, и ваш парсинг обрывается на

Code:

{
"Common":{
"ButtonRadius":0,
"WindowBorderRadius":3
}
}

И хорошо бы, чтоб в такой ситуации, во-первых, все же причина прекращения парсинга писалась.
Код явно же по какой-то причине прекратил работу на символах ": 3" или " //"?
Ну и во-вторых, чтобы подобное прощалось для JSON файлов. Понятно, что список "ошибок",
подобных этой, еще тока будет наполняться, но надо же с чего-то начинать)))

#4: Author: little-brother,

Posted: Thu Mar 17, 2022 16:40
—
olegvsk,

#5: Author: Destiny,

Posted: Thu Mar 17, 2022 18:12
—
little-brother
Стопэ)))
Всё под контролем!
Ничего Wink

не забыто и всё используется как надо)))
Но кое-кому надо помочь, чтобы товарищу было уютнее в этой версии плагина.
А мы с вами ещё погуляем на именинах очередной версии плагина)))

#6: Author: olegvsk,

Posted: Thu Mar 17, 2022 23:48
—
Destiny,

Quote:

Т.е. файлов, где нет одного элемента верхнего уровня

Ну, ошибки в структуре могут быть какие угодно, под каждую подпорку не сделаешь. Мне, честно говоря, крайне редко встречались ЧАСТИЧНЫЕ xml. Но, возможно, кому-то это действительно будет полезно.

Quote:

При генерации XPath для повторяющихся тегов вы не вставляете адресный идентификатор [i]

У меня XPath используется для фильтрации тэгов, т. е. служит предикатом запроса. С индексами в пути такой фильтр работать не будет.

Quote:

И хорошо бы, чтоб в такой ситуации, во-первых, все же причина прекращения парсинга писалась

Согласен, какую-то ошибку надо показывать.

Quote:

Ну и во-вторых, чтобы подобное прощалось для JSON файлов

Поскольку комментарии форматом JSON не описаны, трудно формализовать, что именно нужно прощать, у каждого может быть свой вариант дополнения формата.

#7: Author: Destiny,

Posted: Fri Mar 18, 2022 14:01
—

olegvsk wrote:

Ну дак, речь-то именно и только лишь об одном варианте - когда используешь файлы НЕ финальные, а элементы, из которых потом будет слеплен финал. И вот в отдельно взятом "псевдо"XML файле есть набор своих конкретных тегов, которые сами по себе - совершенно корректны. Так зачем вы обрываете парсинг файла, если не нашли корневой элемент? Считайте это "предупреждением", но всю остальную структуру-то показывайте Cool

. Ведь вы же даже не пишите при открытии такого файла - СРАЗУ не пишите - что была найдена ошибка целостности структуры XML Rolling Eyes

Об этом пользователь узнает - ЛИШЬ! если он откроет режим просмотра CTRL+2! А часто ли люди на него будут переключаться? Они откроют файл, увидят там тока один элемент вместо ...цати - подумают, что в файле ошибка - не тот вывод получен, закроют плаг и удалят файл. И да - я уже подобное видел. Фантазировать на пустом месте мне сейчас не приходится Crying or Very sad

Тут имхо тока два варианта - либо СРАЗУ писать поверх плага с открытым таким "неполноценным" файлом, что найдены ошибки, мол, переключайтесь в режим CTRL+2, чтобы их все увидеть. Либо всё же считать подобное не ошибкой, а формировать втихую тег-заглушку - как корневой элемент. И конечно же второе предпочтительнее, неужели нет?

olegvsk wrote:

Ок, мы знаем, что XPath давно известный язык запросов к элементам xml или xhtml документа. Также как SQL, XPath является декларативным языком запросов. Чтобы получить интересующие данные, необходимо всего лишь создать запрос, описывающий эти данные. Всю «черную» работу за вас выполнит интерпретатор языка XPath. И да, в нем есть вариант этого XPath со скобочками [...] и без. Просто они преследуют разные цели))) Когда я копирую себе ссылку на выбранный элемент - я с вероятностью в 90% хочу увидеть/найти/сохранить именно выбранный элемент, а не всё его подобие. Ибо если я скопирую ВАШ вариант XPath для указанного мной примера /LIST_OF_PERSONS/DATA/PASSPORT/SERIJA и воткну его в спецПО, которое заточено на поддержку и работу среди всех загруженных в него XML, чтобы выполнить поиск НУЖНОГО МНЕ второго элемента - то я получу ВСЕ элементы. Согласитесь, что УДАЛИТЬ ненужные скобочки мне будет куда-как проще (ЕСЛИ вдруг я на самом деле преследовал целью выбрать ВСЕ схожие теги из структуры XML), нежели чем добавлять их, ТОЧНО не зная - а на каком по порядку следования схожем(pattern-matching specification) теге находится нужный мне элемент Rolling Eyes

. Но чаще нужно именно точечное действие после копирования - т.е. получение именно из ....дцатого элемента искомого значение. И тогда это значит, что из /LIST_OF_PERSONS/DATA[2]/PASSPORT/SERIJA мне вроде как проще получить /LIST_OF_PERSONS/DATA/PASSPORT/SERIJA, чем обратное преобразование, особенно когда я не знаю эту ...дцатость, это число 2 в моем примере. Так может тогда разрешить это противоречие простым как мир способом - сделать ДВА варианта копирования? Первый вариант - точное следование иерархии и для моего примера оно даст /LIST_OF_PERSONS/DATA[2]/PASSPORT/SERIJA. И второй вариант - для выборки подобия и для моего примера оно даст /LIST_OF_PERSONS/DATA/PASSPORT/SERIJA, ну т.е. то, что уже сейчас и есть. И с фильтром тогда становится понятно - по какому XPath он работает: по выборке подобия.

olegvsk wrote:

Поэтому я и написал сразу:

Quote:

Понятно, что список "ошибок", подобных этой, еще тока будет наполняться, но надо же с чего-то начинать)))

Не может же быть такого, чтобы плагин работал ЛИШЬ и ТОЛЬКО для четко формализованных и целиком безгрешных по формату JSON файлов.

Last edited by Destiny on Mon Mar 21, 2022 12:31; edited 7 times in total

#8: Author: olegvsk,

Posted: Fri Mar 18, 2022 20:13
—

Destiny wrote:

Я понял ваши пожелания, постараюсь учесть их.

#9: Author: BlackFox, Location: Mayence

Posted: Wed Jul 27, 2022 14:54
—
Добрый день.
есть мелкие пожелания к плагину XML Review, а именно - добавить тёмный режим. В АПИ к листер плагинам есть определение активности тёмного режима, из которого можно его активировать.
Пока руками попытался исправить цвета под тёмный режим - почти все цвета меняются. Из того, что не меняется:
1. цвет структуры XML (знаки < > = --> " / и т.п.) - всегда тёмно-синий.
2. фон активной линии в дереве - всегда белый.
3. все элементы плагина (строка статуса, скроллбары, поле для номеров строк, рамки элементов управления) всегда серые.
Ещё хотелось бы выделение цветом текущей строки (той строки, где находится курсор) в тексте.

В остальном - плагин удобный, на открытие работает быстро (на открытие 60МЬ ХML файла с закрытыми ветками тратит всего 4 секунды - быстрее только Foxe, JSON 3МБ - тоже 2 секунды). Но: открытие всех веток в этом 60МБ XML-файле занимает 92 секунды, тоталкоммандер при этом вообще не реагирует ни на что. Повторное отрытие этого же файла (без веток) приводит к MsgBox "FILEINFO_WLX Address of MappedFile > 4GB" с кнопкой ОК, после нажатия которой, правда, всё вроде бы и дальше работает.
Последняя хотелка - в поиске можно реализовать настройку "по границе слова", чтобы искать только это вхождение (например, при поиске eth1/1 выдавать только вхождения eth1/1, а не все, включая eth1/17, eth1/11 и т.д.)?
Можете посмотреть, что из этого можно реализовать или исправить?
Заранее спасибо!

Last edited by BlackFox on Tue Aug 02, 2022 10:31; edited 1 time in total

#10: Author: junk,

Posted: Wed Jul 27, 2022 19:44
—
Добрый день!

olegvsk, сделайте пожалуйста выбор сохранения настроек, а то сейчас ini-файл всегда создаётся в папке плагина, которая может быть недоступна для записи.
Ну или хотя бы берите путь из DefaultIniName на SetDefaultParams, чтобы пользователь мог поменять.
Спасибо.

#11: Author: olegvsk,

Posted: Sat Jul 30, 2022 16:39
—
BlackFox,
Здравствуйте.

Quote:

добавить тёмный режим

Попробую, или просто добавлю настроек цветов.

Quote:

выделение цветом текущей строки

Это можно.

Quote:

MsgBox "FILEINFO_WLX Address of MappedFile > 4GB"

Не сталкивался с таким. Подозреваю, это сообщение из другого плагина. Вот здесь обсуждают.

Quote:

реализовать настройку "по границе слова"

Сделаю.

Добавлено спустя 9 минут:

junk,
Добрый день.
Думаю, вариант с DefaultIniName оптимален, сделаю так.

#12: Author: BlackFox, Location: Mayence

Posted: Sun Jul 31, 2022 15:36
—

olegvsk wrote:

BlackFox,

Quote:

MsgBox "FILEINFO_WLX Address of MappedFile > 4GB"

Не сталкивался с таким. Подозреваю, это сообщение из другого плагина. Вот здесь обсуждают.

Да, что-то не обратил внимания на заголовок, в котором написано,что это не Ваш плагин. Тогда забейте.

#13: Author: junk,

Posted: Thu Aug 04, 2022 18:07
—
olegvsk,
Ещё вопрос. В чём смысл кастомного окна поиска? Почему не используется стандартный тоталовский? Из-за этого при переключении между плагинами текст приходится заново вбивать. История поиска опять же своя почему-то.
Ещё Ваш диалог поиска хоть и модальный, но почему-то иногда оказывается "за" окном листера, из-за чего листер не реагирует ни на что.

#14: Author: olegvsk,

Posted: Tue Sep 20, 2022 18:21
—
Выложил новую версию http://totalcmd.net/plugring/xmlreview1.0.html.
Подсветка текущей строки, несколько новых настроек цветов, настройка "Whole words" в поиске, выбор расположения ini файла. Добавил сортировку узлов в дереве.

junk
Исходил из того, что у специализированных плагинов должна быть своя история поиска. Понятно, что кому-то удобно так, кому-то иначе.

Quote:

Ещё Ваш диалог поиска хоть и модальный, но почему-то иногда оказывается "за" окном листера, из-за чего листер не реагирует ни на что.

Есть такая проблема. Слегка доработал, сейчас окошко не должно теряться.

#15: Author: junk,

Posted: Thu Sep 22, 2022 12:46
—
olegvsk, спасибо за обновление, стало лучше!
По поводу кастомного поиска не разделяю Вашего мнения, мне кажется одно окно гораздо удобнее, особенно когда текст ищется в файлах разных типов. Вы легко поймёте, например, ищется значения и в конфигах (xml), и в исходных текстах (c/cpp/h/etc), приходится искомую строку дважды вбивать, а так хваталобы одного (!) нажатия F3 в каждом новом окне.

Ещё момент, похоже иногда плагин кидает исключение на выгрузке (тотал показывает окно с эксепшном).

Total Commander -> Плагины Total Commander

output generated using printer-friendly topic mod. All times are GMT + 4 Hours

Goto page 1, 2, 3 Next :| |: Page 1 of 3