Войти
ФлеймФорумПрограммирование

XML - язык, невероятно богатый возможностями. Чтоб его. (6 стр)

Страницы: 1 2 3 4 5 6
#75
23:34, 6 авг. 2019

gudleifr
> А несамописные, разумеется, сами "специализируются под задачу"...
А несамописные из коробки в десять тысяч раз распухли.


#76
16:03, 7 авг. 2019

gudleifr
> И проблема даже не в том, что "парсер" - это две строчки кода. А в том, что в
> Вашей постановке задачи, при которой эти "2 часа" через полгода обойдутся
> месяцем на переписывание.
За 10 лет ни разу не переписывались. Это твой велосипед придётся каждый раз допиливать, когда что-то ещё надо будет поддерживать.

Sbtrn. Devil
> Какие шаблоны? Гуйно-DOM-ные? За гуйно-домные шаблоны, связанную с ними модель
> и запросы отвечает гуйно-домная библиотека. Шаблоны данных, которые нужно
> откуда-то там достать, отфильтровать и как-то представить? Так это не
> самостоятельная задача - за неё отвечает или БД, или какая-то
> узкоспециализированная модель, и это опять-таки сфера ответственности БД или
> модели, а не формата.
Ни хрена не понял, я про XSLT говорил. И БД тут совсем не в кассу, мало того, что движок БД надо с собой таскать, так ещё и кода навернуть вокруг на порядок больше.

Sbtrn. Devil
> Вот уж где хмл нужен меньше всего, так это для конфигов и логов.
Да конечно. Я вроде уже пояснил, что для конфигов нужен нормальный стандартизированный формат, который а) поддерживает схемы, б) позволяет делать запросы. Я конечно хз, может тебе и ini-файл за конфиг сойдёт, но я такое последний раз 10 лет назад использовал.
Что касается логов - есть одно традиционное простое и неправильное решение - plain text файл, где строки отделены через \n или \r\n (уже попадаем в проблемы), а поля разделены табуляцией (не забываем при этом из входных данных убрать неподходящие символы). А потом для разбора терабайт логов корячим свои скрипты для ES и чтобы оно нормально парсилось. А потом кто-то что-то меняет в выхлопе логгера и терабайты косячно разобранных логов улетают в БД. А пробовал когда-нибудь читать логи длинною в сотни Мб? Когда там сплошная портянка текста?

Sbtrn. Devil
> В таких случаях пилится специальный модуль, отвечающий строго за работу с
> конфигом, и все модули-юзеры, заинтересованные чего-нибудь конфигурировать,
> общаются с конфигурацией строго через его интерфейс. Реализация всех
> поисков-запросов, представления конфига и проч. - на нём. Какой формат будет
> подпирать с человекочитаемой стороны - дело уже глубоко десятое, т. к.
> модули-юзеры читать из него сами ничего не будут, это не их собачье дело.
да, это будет дерево объектов конфигурации, к ней мы напишем свой язык для запросов и придумаем свой формат для хранения. Всё это будет в 1000 раз хуже, чем стандартный XML, работать всё будет в 100 раз медленнее, зато мы потратим на это 200-300ч. Ну т.е. это работодатель потратит, мы-то за это денюжку получим, ага? ;)

Sbtrn. Devil
> В таких случаях к задаче бывает полезно уточнять один момент: "...и заполнять
> этот конфиг будешь ТЫ!" Этого уточнения обычно хватает, чтобы 2ч магическим
> образом превратились и в 8ч на постановку задачи, и прочие "такие вещи с
> кондачка не решаются, надо сначала подумать как следует".
нет таких проблем, не придумывай. Весь софт написанный на .NET (включая веб-решения) имеет конфиги в виде XML.

#77
16:08, 7 авг. 2019

Мизраэль
> За 10 лет ни разу не переписывались.
И Вы до сих пор помните, что 15 минут ушло на писание и 2 часа на хабр? Круто Вас тогда цепануло...

#78
13:00, 8 авг. 2019

Мизраэль
> Ни хрена не понял, я про XSLT говорил.
Вот это точно не нужно. Человекочитаемый формат должен заканчиваться в том месте, где он проходит через парсер. Все дальнейшие трансформации - в терминах внутреннего представления, и никаких извращений не нужно. А если вдруг нужно много-много данных, которые не влезают в тривиальное внутреннее представление, и всяко-различно комбинировать их выборку - БД очень даже в кассу. Там по вопросам выборки данных за десятилетия съедены тонны собак, и Xpath сотоварищи - убогий эрзац супротив SQL.

> А пробовал когда-нибудь читать логи длинною в сотни Мб? Когда там сплошная
> портянка текста?
Как раз для чтения сотен мб портянка текста - идеальный формат. По ней может работать даже примитивный греп.

Мизраэль
> да, это будет дерево объектов конфигурации, к ней мы напишем свой язык для
> запросов и придумаем свой формат для хранения. Всё это будет в 1000 раз хуже,
> чем стандартный XML, работать всё будет в 100 раз медленнее, зато мы потратим
> на это 200-300ч. Ну т.е. это работодатель потратит, мы-то за это денюжку
> получим, ага? ;)
Я тут прямо сейчас работаю именно с таким решением. Внизу у него, сюрприз, самый что ни на есть стандартный XML (в нём конфиг хранится на диске). Очевидно, что на заре его сочинители думали примерно так же, как ты. С тех пор прошли годы. Система обладает следующими фичами:
- интерфейс для выдачи конфига другим компонентам. Очевидно, что это было сделано в первую же очередь, т. к. голая модель данных хмл оказалась неудобным говном. И по ряду корявых решений в этой модели видно, как её сначала прибивали гвоздями именно к хмл (ну а чо там, запросы и всё такое), а потом долго и мучительно отдирали. Естественно, парсер хмл во внутреннее представление компонента, отвечающего за конфиг, имеет место быть. И, естественно, компоненты потребляют конфиг именно во внутренней форме, и ни про какой хмл знать не знают.
- интерфейс для выдачи конфига компонентам по сети. Т. к. конфижный сервак один, а заинтересованные в конфиге компоненты чаще всего распределены по другим хостам. Предусмотрено проксевание и балансировка нагрузки.
- скопинг частей конфига для отдельных компонентов и отдельных хостов. Т. е., обычный вариант конфига может быть один, но для такого-то компонента на таком-то хосте вместо него может действовать другой.
- метадата. Никаких XSD, потому что метадата в терминах предметной задачи оказалась сильно не такой, как казалось афторам XML. Её пришлось пилить в отдельных файлах, причём разделение файлов регламентировано строго определеным образом: у каждого компонента своя метадата, и она может обновится при апдейте/патче.
- веб-гуй для человекоредактирования и человекопросмотра конфига. Потому что в хмл-виде размер конфига исчисляется семизначными цифрами, плюс соображения разграничения доступа, и ни о каком просмотре и редактировании блокнотом речь даже не идёт.
- инструмент командной строки для редактирования и извлечения частей конфига. По тем же соображениям, что и выше. Имеет место самописный язык запросов. Да, в терминах модели данных конфига, а не нижележащего хмл. Да, его пришлось велосипедить, потому что xpath не умел работать в этой модели. Да, изменения конфига в патчах поставляются именно на этом самописном языке. Некоторое время назад было принято решение о переводе на него же дефолтных конфигов, применяемых при инсталляции компонентов (ранее они описывались в т. н. canned data - кусках хмл, которые при инсталляции впатчиваются в соотв. место главного документа). О причинах решения догадаться нетрудно.
- поддержка кустомизируемых валидаторов. Да, они тоже должны вести валидировать в терминах модели данных конфига, более того - в логике конкретного компонента. И да, их поддержку тоже пришлось велосипедить, потому что модель данных конфига и возможных ограничений выходила за пределы возможностей не только хмл-схем, но даже самописной метадаты.
- это только те фичи, о которых я на сегодня знаю...

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

> нет таких проблем, не придумывай. Весь софт написанный на .NET (включая
> веб-решения) имеет конфиги в виде XML.
У вас там, может, и нет проблем, а у нас внедрение нового куска конфига в процессе разработки новых фич в компонентах перестало быть танцами с бубном и блокнотом только после разработки ряда велосипедов.
Ну а .нет - известное говнистче. К счастью, у нас не он.

#79
13:23, 9 сен. 2019


https://www.joelonsoftware.com/2001/12/11/back-to-basics/

Страницы: 1 2 3 4 5 6
ФлеймФорумПрограммирование