?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
(no subject)
nyaload
_winnie
При модификации xml при помощи DOM-библиотек есть проблема, что библиотека сохраняет xml в таком форматировании, в котором ей нравится. Например, удалил одно поле из xml, а текстовый diff показывает что изменилось ВСЁ. И редактировать руками потом такой документ неудобно, отступы нечеловеческие. Это связано с тем, что библитека превращает текст в дерево, и забывает про все те пробелы и пустые строки, которые поставил человек, про красивое форматирование атрибутов.

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

PS. диффы можно смотреть пересохранением файлов, и гугль с apt-cache говорят про существование неких xmldiff.
Tags: , ,


  • 1
редактировать руками? xml? у вас явно неправильно что-то

Если его не редактировать - то смысл в xml? Есть же бинарные форматы на основе TLV.

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

во-вторых - при программном доступе формат не особо интересен. Интересна распространённость и наличие библиотек, которые позволяют удобно с ним работать. Для xml это есть, а для tlv что-то не очень.

Эм.
Какой-нибудь конфиг в xml.

Не писать же по GUI-редактору на каждый xml. В любом крупном проекте дофига мелких xmlек которые пишутся руками, помимо тех для которых сделан какой-нибудь гуи-редактор.

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

Edited at 2010-11-20 10:19 am (UTC)

а может попробовать xml editor... кто-нить посоветует, пожалуйста, желательно бесплатный?
пробовал xml shell, не понравилось

кстати, а что если diff умел бы показывать логическую разницу в xml?

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

Есть режим чтения, который сохраняет полностью такой тег?



Сомневаюсь что-то.

Чертов HTML.

<tag

attr1    =    'value1'
   attr2  = "value2"

/>

а, вы об этом? да, есть такое. хотя вроде некоторые библиотеки могут выравнивать атрибуты при сохранении.

Эта хрень вставляет лишние пробелы там, где не надо. А научить, в каких тегах вставлять пробелы, а какие оставлять как было, его нельзя, в отличие от xmlformat, например.

я в общем-то уже говорил: можно сделать сейвилку xml-а, которая будет читать форматирование оригинального файла и пытаться матчить новые данные в старые, чтобы по максимуму сохранить порядок элементов и их форматирование.

Выше уже сказали, что есть режим при котором все строки из пробелов и переводов строк тоже суются в dom.
В pugi, например, это называется parse_ws_pcdata, в libxml называется preserveWhiteSpace, вообще включено по-умолчанию.

Выше уже привели пример с отступами внутри атрибутов

А... атрибутов. Ну тогда звиняйте.
Пример выше -- это уже изврат. С такими проблемами хранить их надо как дочерние узлы.

XML не является human readable. Редактировать его руками уже ошибка.

Это в теории. На практике ты наверное и сам много раз нарушал этот тезис ;)

Ну и если бы он и на практике, а не только в теории был не human-redable (пусть и на 3+ или 4-, а не на пятёрку), то смысла в нем вообще не было бы.

В том-то и дело, что можно быстро без XSLT поправить найти и поправить опечатку в ресурсах, скопировать ноду как текст и вставить в другое место, поискать регулярным выражением или тупо Ctrl+F ссылки на текстуры, использовать как конфиг-файл.



Edited at 2010-11-20 11:25 am (UTC)

Это в варианте "прохачить быстрее", вроде массовой перенастройки путей в VS проекте.

Но когда данные свои - можно делать правильно. Т.е. вот случай с текстуркой - редактор может найти всех акторов такого-то и такого-то типов, у которых одно или более из свойств содержит в значении такую-то текстовую строку. Теперь можно либо поменять свойство на выбранных акторах (единичным действием), либо клацнуть на запуск юзерского скрипта на Lua, который обработает их более сложной логикой. Скрипт дизайнеры сами не напишут, но можно направить к ним человека, который за полчаса всё сделает. Так у меня редактор работал, во времена в геймдеве. Времени экономилось дохуприлично.

>Но когда данные свои - можно делать правильно.
Можно делать правильно за полчаса, а можно за секунду заменить десять "Monstr.png" на "Monster.png"

И даже не мучаться, "сохранить или выкинуть ли скрипт, вдруг ещё понадобится".

А конфиг-файлы? Писать их на xml потому что традиция и библиотеки, но считать что это не xml, а текстовый файл, а то что расширение xml и в начале стоит <?xml version="1.0" encoding="UTF-8"?> - так это просто совпадение для нашего как бы формата конфига? А syntax-подсветка и автокомплит тегов в текстовых редакторах - это вообще непонятно что.

Edited at 2010-11-20 12:13 pm (UTC)

"Monstr.png" на "Monster.png" в пару кликов меняет дизайнер, без участия программистов. Это и называется делать правильно.

Что касается конфигов, то у тебя какой-то махровый Java-way. Когда в проекте используется один из динамических языков (Python, Lua, ...), то config/startup проще сделать прямо на нём, если нет - JSON со всем счастьем и подсветкой. При наличии редактора дублируется диалогом настроек.

тем не менее именно хуманридабильностью популяризаторы xml постоянно тыкали в морду лица, когда впихивали xml в широкие массы через все физиологические отверстия

ну а теперь-то конечно, раз с иглы не соскочат, можно и человеконечитаемым объявить :)

Однако, даже в вебдеве (где терпят любой срач от W3C) зародился JSON, применяемый теперь много где. Это не проблема, люди делают свой выбор.

почему "даже", в вебдеве выбор делать проще, там новые проекты чаще возникают, да и они по большей части не особо крупные и бюрократии поменьше

перевести какой-нибудь кровавый энтерпрайз с километровым слоем древнего унаследованного кода на другой формат посложнее будет

а выбор сделать всегда можно - некоторые даже с героина слезают, говорят

(Deleted comment)
Разумеется не человекочитаемый. Для сравнения можно посмотреть и оригинальный TeX, и современные разметки wiki, и другие языки данной предметной области за последние лет 40.

(Deleted comment)
Продолжайте их "читать", не возражаю. Когда-то данные перфокартами вводили, тоже люди читали, записывали, могли subroutine в машкоде по дырочкам узнать.

помнится в .net существовало специальнон свойство, которое заставляло парсер хмл сохранять полностью все форматирование, вплоть до каждого символа

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

  • 1