OberonCore

Vlad писал(а):


Да, давайте камасутрить по полной: Наваять .dll-ку в FPC, придумать промежуточный формат данных для передачи в ББ, а в самом ББ это дело расшифровать в необходимый для работы формат данных.

Давайте не надо спорить впустую. Как говорил один мой друг: "Делать, так делать. А не делать, так ничего не делать"(орфография сохранена).

MSXML -- это конечно хорошо(наверное), но это опятьполучится частный случай. Или я безпробудно увяз в FPC-принципах работы?

Мы используем FPC-шный парсер, использовать его для BB - дело не менее простое - подключить DLL и наслаждаться. Речь идёт именно о "родном" компоненте.



Я вот не понял. Подключить компонент для работы с XML, который использует другой компонент для работы с XML. Огород какой-то
Зачем XML-парсеру использовать внешние парсеры, да ещё сомнительного качества?

А он совместим с DOM?

Вам шашечки или ехать? Нормальные парсеры на коленке за 5 минут не пишутся.





Этот "огород" есть не что иное как "абстрагирование от деталей реализации". Основополагающий принцип КОП.



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

Влад, я согласен с вами в том плане, что лучше использовать готовое, чем изобретать велосипед.

Лично мне "родной" парсер импонирует в аспекте контролируемости кода и удобства дистрибуции.

Насчёт проверенности MS XML в этой ветке уже писали.

Другой момент - почему-то в составе компонентов FPC парсер свой, а не обёртка над сторонними парсерами. Маньяки, наверное. Чего бы не юзать уже готовые компоненты, непонятно.

Аргумент про масштаб использования не "катит", виндовс юзают миллионы, несмотря на её каличность. Про способность мелкософта при первой же возможности изобретать свои стандарты тоже известно.
Но это уже оффтопик, разговор за общую перспективу.

Разговор свернул на хорошую плоскость, подняв вопрос - что лучше для сообщества BB, использовать сторонние компоненты XML или заиметь свой парсер, совместимый с DOM?

Если учесть, что MS XML идет вместе с виндами, то я не очень понимаю в чем проблема дистрибуции.



Угу. Я лично проверял. Работает.



Наверное. Например на моей прошлой работе юзали дельфовый компонент (забыл как конкретно называется). Просто потому, что глючный C++Builder не смог сгенерить обертки для MS XML. То, что такая обертка пишется ручками за 20 минут никто просто не знал. Хотя и не ламеры работали, но вот с COM не были знакомы. Когда меня наконец достало "качество" это компонента (мегабайтный паскалевский файл с видимыми невооруженным взглядом кусками копипаста, как сейчас помню) я подменил его на MS XML. Ничего страшного не произошло, только глюки в виде всяких Access Violation исчезли. Толку в наличии и "контроллируемости" исходного кода, если он такого качества, что все равно в него не полезешь ничего исправлять?



Несмотря на ее калечность - лучшего все равно до сих пор не предоставили. А докопаться можно к чему угодно.



Конкретно к MS XML есть претензии?



Дык, готового родного парсера все равно нет. Помечтать, конечно, можно...

заиметь свой парсер, совместимый с DOM

BB работает с COM напрямую. Соответственно FPC и какие-то dll - не нужны.

Иногда встречаются и древние винды, для которых надо ставить парсер отдельно. Кроме того, сколько версий MS XML уже сменилось? Есть шанс попасть на несовместимость. Ну да ладно.



Масштаб, конечно, несравним - с тем же FPC



Да код уже есть, FPC-шный, испытанный и проверенный. Кстати, открытый.



Дык Влад, посмотрите - форум про ББ, вопрос про новый компонент к каркасу, а вы предлагаете использовать MS XML. Спасибо, конечно, за информацию, но логика форума несколько другая, как мне кажется.
Вы спрашивали - "шашечки или ехать"? Я отвечу - ехать, как можно комфортнее и надёжнее, с хорошей перспективой.
А те, кому надо побыстрее "приехать", выбирают VB



Вообще, уже столько всего в мире понаписано, чего мы тут собрались-то? Бери да компонуй.

Ты действительно сбираешься распространять свои приожения на что-то более древнее чем Windows 95, OEM Service Release 2.5 или IE4.0?



А для этого в COM есть механизм версионности.



Ладно. Допустим MS XML закрытый. Чем какой-нибудь Xerces хуже? Его большую испытанность (по сравнению с FPC) будешь оспаривать ?



Когда?



Я только хотел сказать, что велосипед в виде родного XML-парсера для BB достаточно дорог, а потребность в нем на текущий момент чисто эстетическая.

Просто так хаить, не давая ничего взамен, конечно не хорошо, согласен. Однако, все же позволю себе похаять. Учитывая, какие ресурсы задействованы у MS, миллионы имеют полное право требовать качества, а не глюков. Особенно, учитывая то, что эти ресурсы они употребляют не только на разработку, но и на то, чтобы проталкивать свой "калич", задавливая своих более слабых конкурентов, которые, возможно могли бы написать что-то более качественное. Вот такое мое оффтопиковское мнение.

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

Возражу только вот на что.
Ты говоришь, что делать свой парсер дорого. Согласен. Развивать и поддерживать платформу - штука вообще дорогая. А когда вкладывать в ББ, если не сейчас? Кроме парсера XML, в ББ много чего не хватает, но меня это не останавливает. Слишком хорошо этот ящик устроен, чтоб использовать его как подставку для DLL

Разрешите вопрос: а что значит "совместимый с DOM" парсер? Это такой, который дерево документа в памяти строит?

Парсер XML - это не компилятор C++. Задача вполне выполнимая за приемлемые сроки.

Да-да, вот спецификация DOM:
http://www.w3.org/TR/DOM-Level-2-Core/

Ты в упор не хочешь видеть то, что "вкладывание" - вещь количественная и исчислимая. И от того, по каким направлениям распределятся усилия, зависит хорошесть этого ящика в конкретный момент времени. Например, я бы предпочел иметь BB с нормальной поодержкой многопоточности и зависимостью от MS XML (или какой другой либы), нежели в том состоянии, в котором он сейчас, но зато с родной либой для парсинга XML.

Исчисляю. Парсер - раз. Многопоточность - два. Поддержка дружественного интерфейса - три. И так далее.



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

А я и не говорил, что она невыполнима. Я говорил, что она не первоочередная. И даже не второстепенная. Я бы отнес ее к классу proof of concept - "и на компонентном паскале можно написать парсер XML".

P.S. Как насчет родного SQL сервера? С поддержкой stored procedures на компонентном паскале? Задача вполне выполнимая за приемлемые сроки. А то приходится ходить ко всяким MS SQL и прочим MySQL (которые написаны на глючном С).

Ответ - не растрачивать усилия на велосипеды в виде родных XML-парсеров.

Влад, Вам же никто не ставит задачу написать парсер XML. Если народу требуется встроенный в ББ парсер - да пожалуйста! Пусть пишут, значит им оно нужно.

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