Total Commander

Можно добавить настройку для отключения этого столбца, если он так мешает.

little-brother писал(а):я на одиночных узлах не проверял, т.к. для них смысла нет. Как оказалось зря

А я-то и не знал - что они одиночные !
Вот если бы отсечение по XPath работало))))))

Добавлено спустя 29 секунд:

little-brother писал(а):Можно добавить настройку для отключения этого столбца, если он так мешает.

можно просто сделать его всегда скрытым, ИМХО...
И поиск тогда продолжать будет работать и визуализация будет ровно того, что представляешь увидеть, а не чего-то еще лишнего)))

не знал - что они одиночные

Проблему нашел уже и пофиксил. Оказалось немного из-за другого.

если бы отсечение по XPath работало

Пока надеяться на то, что появится XPath в каком либо виде, не стоит.

little-brother писал(а):Пока надеяться на то, что появится XPath в каком либо виде не стоит

Главное, что есть его копирование! Офигенно вовремя появилось!

Копирование сделать было просто, в отличии от обхода XPath. Разбор XPath достаточно нетивиальная задача, если самому писать.

Чтобы что-то появилось - надо просто написать об этом Я ж не пользуюсь плагином, потому и не знаю, что можно улучшить, а что исправить (#CONTENT в следующей версии будет отключен по умолчанию).

Потенциальная ошибка! вроде бы.

создаете файл с пятеркой тегов
<X>
....тут какие-то внутренние подтеги
</X>
<X>
....тут какие-то внутренние подтеги
</X>
<X>
....тут какие-то внутренние подтеги
</X>

по текущей встроенной логике этот неверный xml обкладывается тегом
<root$>...</root$>

Теперь берем, выделяем какой-нить подтег в узле последнего Х
и вызываем команду Copy XPath.
Получим: /root$/Х/подтег
А должны были: /root$/Х[5]/подтег

P.S.
Для XML, у которого сразу верная "окантовка" тегов одним внешний есть - там все так же странно/неверно.
Но. т.к. сперва в глаза бросилось именно на "особом"/неверном XML, то с него и начал описание проблемы.

Проверял на проге Altova XMLSpy - один из мировых лидеров по обработке XML, JSON и многих схожих файлов...


P.S. конечно же теги закрываются. Подправил пост после прочтения нижеследующего, чтоб потом, если что - читалось нормально.

[s]А вы точно тег закрыли? В приведенном примере узлы X не закрываются, что может давать столь странный эффект. Лучше конечно полный XML, на котором проявляется ошибка, привести.

Те, документы, на которых возникает ошибка в плагине, они точно валидные?[/s]
Похоже для последнего узла XPath формируется с ошибкой. Для остальных вроде норм, т.е. надо цикл переписать.

Просьба проверить фикс - https://disk.yandex.ru/d/PumEzKRnVzCqvg

little-brother писал(а):Просьба проверить фикс

да, работает норм!

и да - в своем посте я ошибся с закрытием тегов Х: вручную же набивал их. сейчас пост подправил, чтоб читалось на потом - адекватно.

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

Подозрение: в том же файле 3.xml первые три строки:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="book.xsl"?>
<!DOCTYPE book SYSTEM "schema.dtd">

ИМХО, они не так показаны для дерева тегов.
Ожидается это: Разбор ведется по схеме:
<!DOCTYPE root_element SYSTEM "DTD_location">
SYSTEM - ключевое слово определяющее, что DTD объявлен приватным внешним файлом разметки.
Бывает PUBLIC вариант - противоположность SYSTEM)))
Тогда схема DOCTYPE усложняется:
<!DOCTYPE root_element PUBLIC "DTD_name" "DTD_location">
И тогда у нас появляются в таблице чуть другие данные. К примеру для строки:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
мы увидим:
KEY="#root_element" VALUE="HTML"
KEY="#keyword" VALUE="PUBLIC"
KEY="#DTD_name" VALUE="-//W3C//DTD HTML 4.0 Transitional//EN"
KEY="#DTD_location" VALUE="http://www.w3.org/TR/REC-html40/loose.dtd"

Ну и XPath для этих строчек должен возвращать пустую строку. Ибо это препроцессорные директивы по сути для последующего валидного тела XML. Они не входят в XPath для XML.

Для этого придется библиотеку парсера править, что несколько лениво.
В третьем случае вообще свой парсер нужен

<!DOCTYPE [Элемент верхнего уровня] [Публичность] "[Регистрация]//[Организация]//[Тип] [Имя]//[Язык]" "[URL]">

Так что скорее всего пока останется как есть, тем более, что это не сильно критично.

little-brother писал(а):Для этого придется библиотеку парсера править, что несколько лениво.
В третьем случае вообще свой парсер нужен

Жаль, что библиотека так неподготовлена)))
Ну ок, будем жить с тем, что есть.
НО! третий случай разбирать ТАК глубоко не стоит. Свой пост отредактировал - показал достаточность разбора.
Т.е. выборку подэлементов [Регистрация]//[Организация]//[Тип] [Имя]//[Язык] вообще не ожидалось увидеть.

Библиотека с базовым функционалом. Выбрал из-за небольшого размера и понятного кода, который при необходимости можно поправить (что и было сделано). А то, что часть функционала нет - издержки

Кажется еще один глюк разбора нашелся.
Строка атрибутов:
Checked="true" ID="1" Position="2" Prefix="services_items" jsonSettings="" minNumberLength="3"
можете вставить куда угодно для тестов - под любой тег.
При парсинге в таблице справа происходит разбор вот такой:

как видно - кое что не туда "полетело"(((

Фигово. Это проблема в парсере, а копать его то еще удовольствие.
Насколько могу судить проблема в пустых значениях, т.е. "".

little-brother писал(а):Это проблема в парсере, а копать его то еще удовольствие.

хотя же его

little-brother писал(а):Выбрал из-за небольшого размера и понятного кода, который при необходимости можно поправить (что и было сделано)

глупое предложение - может новый парсер настало время выбрать для основы плагина?

А смысл? Тот, который с XPath, я просто не соберу, да и сам плагин станет 1-2мб весить и при этом не использовать 99% функционала.

Немного покопал и баг нашелся. Плюс этой либы в том, что в ней мало кода и он достаточно понятен.