Комментарии 13
но лицензия GPL не позволяла использовать данное решение в наших продуктах.
Мы проговаривали с юристами, если ваш продукт не форк GPL-продукта, а лишь использует, то делаете два инсталлятора: один для чистых лицензий и вашего кода, а второй - для gpl-библиотек. При установке запускаете два отдельных инсталлятора. Если микросервисная архитектура, то gpl-компоненты обертываете в сервисы. Если у вас один контейнер с приложением и gpl-компонентами, то собираете контейнеры из двух инсталляторов в прод среде. Все это нужно не для удобства разработчиков, а для того, чтобы не показывать весь код, когда запросят интересующиеся. #подстелитьсоломку #подорожник
Линковаться с GPL библиотекой нельзя, не публикуя свой код под GPL. Даже если не распространяете GPL-код вместе с продуктом. Как раз распространять код вместе GPL не запрещает. Линковка же весьма спорный момент, но по факту большинство разночтений сводятся к тому, что линковка к библиотеке подразумевает включение ее логики в программу, и тогда вся программа должна быть опубликована под GPL. Есть LGPL, которая разрешает линковку к LGPL библиотеке без публикации кода остальной программы. А еще есть AGPL - самая лютая хрень, с ней даже обернуть в отдельный сервис, который доступен по сети, нельзя, не выкладывая весь свой код под AGPL.
В связи со всеми этими сложностями, большинство мест, где я работал, основная идея была "не использовать GPL-код, если это возможно", чтобы не иметь всех этих заморочек.
Приходилось работать и с DOM и с SAX.
Для себя критерий такой - если документ невелик (и помещается в памяти) и с ним нужно работать как с документом (открыл - отредеактировал - сохранил - закрыл) - DOM.
Если нужно просто получить какие-то данные, которые приходят в виде XML, которые нужно как-то обработать (в настоящее время у нас это приходящий откуда-то извне документ, из которого нужно извлечь интересующие нас данные и разложить их по нашей БД) - SAX без вопросов.
Если сравнивать со шкафами:
DOM - сначала все вещи выкладывает из шкафа и раскладываете в нужном порядке на полу. Потом уже делаете с ними то, что нужно. Можете потом, если надо, сложить обратно в шкаф.
SAX - берете вещь из шкафа, если нужная - используете или кладете в стопочку. Ненужные сразу выкидываете в окно. Сложить все обратно в шкаф будет уже отдельной задачей.
На нашей платформе в том языке, который в основном используется, есть встроенный XML-SAX для которого пишется хэндлер, обрабатывающие генерируемые движком события.
Есть еще более интегрированная XML-INTO которая сразу раскладывает содержимое XML в структуру, но оно работает только с очень простыми XML, "завести" ее для реального для нас XML документа мне не удалось...
С DOM работал давно и не очень много (когда-то была нужда в работе с gpx файлами - это XML, содержащий GPS данные). Не помню уж что тогда использовал, вроде бы TinyXML - для тех задач хватало, глубже не копал.
по аналогии с БД - таблица маленькая, тогда fullscan (построение полной модели), большая - только индексы
А еще есть StAX!
StAX - как раз про "взять следующую вещь из шкафа". А вот SAX - это когда вещи из шкафа в тебя летят сами.
StAX – это про попросить следующую вещь из шкафа, и если дали, а она не подошла, то выкинуть в форточку сразу, не вдаваясь в подробности что там "у ней унутри", а дальше решить просить ли следующую =). То есть по ресурсам получаем меньше чем у SAX, и за меньшее количество приседаний, не получая и не обрабатывая все события: "начало" вещи, "начало" подвещи, "конец" подвещи, "конец" вещи и т. п.
я когда лет 10 назад пробовал разбирать в лоб MS OOXML да OpenDocument в виде приложения, в итоге с OOXML так и "не шмогла"...
сейчас деталей не помню, надо на github.com поднимать код. qt4 тогда использовал. недавно просто пересобрал на qt5, для интереса, но логику не разбирал. давно уже не программирую. хотя есть задачи, которые хотелось бы автоматизировать, но это и sql и qt и дофига всего, а главное - время где найти 8-0 !!!
насколько помню - парсил последовательно, искал нужные "переменные" да "таблицы".
и с таблицами в OOXML было тяжко.
SAX - сложить все обратно в шкаф не составит большого труда, если поставить рядом второй шкаф и вместо форточки складывать вещи в него (получится в том же порядке), а если надо, то заменять их по пути.
ну да, если ни разу не столкивался со взрослыми объемами данных, то само существование SAX подхода может оказаться откровением )
Предпочитаю SAX парсер. Был опыт разгребания частого прихода файлов от 10 гб xml около 10 лет назад. Я ещё юзал Qt 3.5, так вот мой лесопед на 500 срок кода обрабатывал данные файлы за менее чем пару секунд. Найти информацию, сложить в другой файл, поискать ещё. Правда xml были без схем и очень простыми. То есть без якорей и остального непотребства. Но когда я это реализовал, для меня это было откровение, что некоторые вещи можно решать другим подходом, с одинаковым результатом. Это было в начале профессиональной деятельности, мог себе позволить. Сейчас уже ничему не удивляюсь. На оборот всё раздражает:)
Это нужно всем кто работает с отчётами или фактурами. А это много самых разных задач. Было бы здорово не писать самому каждый раз парсинг xml для фактур.
Как и зачем мы парсим XML