IT wrote:

> C>А зачем? libxml есть везде — сам лично компилировал его для PocketPC
> Среди вариантов предложенных eao197 такого варианта не было

libxml2 — было. Вообще, при работе с XML через DOM/SAX и использовании
XPath не так уж и важна конкретная библиотека — разница будет, по
сути,только в синтаксисе.

Например, перевод достаточно большого (4Мб исходников на С++) проекта с
msxml на libxml занял у меня примерно день.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, eao197, Вы писали:


E>Для меня -- ответ. Я сказал

Автор: eao197
Дата: 20.06.05

, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH.
XML Schema позволяет сделать три вещи:
1. Сделать отображение файла в объект класса
2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации
3. Гарантировать, что подача синтаксически корректного, но неверного семантически конфига приведет к внятному сообщению об ошибке, а не к undefined behavior твоего приложения
XSLT в конфигах вроде не очень нужен. Кроме как универсальный способ конвертировать конфиги из одной версии в другую. А, ну еще сделать нормальное отображение конфигурации в браузере. Вообще, кстати, могучая вещь. Сейчас это становится все моднее вообще для произвольных форматов. Вот, к примеру, есть у тебя билд лог. При этом у него с одной стороны, жесткий машинно-читаемый формат, а с другой — дабл-кликаешь его в браузере, а у тебя нормальный человеко-читабельный гипертекст. Конфиг в этом смысле ничуть не хуже.

XPATH позволяет тебе делать такие вещи, как программная модификация конфигов. Ну вот, к примеру, ты написал плагин к чему-то. И тебе надо его в этом чем-то зарегистрировать. В XML ты просто берешь и добавляешь свой тег в соответствующий тег конфига этого чего-то:

...
<extensions>
  <data>
      <extension name="Standard" path="..." author="Initial Author"/>

      <extension name="Cool" path="...\" author="eao197">
            <!-- пошли настройки специфичные для нашего плагина -->
            <Timeout>97</Timeout>
            <!-- конец настроек специфичных для нашего плагина -->
        </extension>
    </data>
</extensions>
...

При деинсталляции ты должен корректно удалить свою веточку, не тронув остальные. Поэтому банальный откат конфига к доинсталляционной версии не катит. Полное считывание конфига в память, правка и сохранение требуют от твоего плагина знания полной структуры. XPATH позволяет тебе найти место для вставки и удаления своей секции при помощи одного запроса. Причем если даже формат конфига радикально поменяется, тебе не придется обновлять свое описание этого формата. Достаточно будет подправить строку запроса XPath.
E>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
Имеет. Но в наше время его применение уже надо обосновывать. Пока что это проще, чем обосновать применение goto, но эта радость ненадолго

Здравствуйте, TK, Вы писали:
TK>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции.
Тут мне буквально позавчера рассказывали про маньяков, которые парсили 60000 килобайт XML (само собой, приезжающего с клиента) в процедуре на MS SQL. И ничего, работает.
TK>Не набросаешь примерный код на T-SQL?
Гм. А у нас разве статей на эту тему мало?

Здравствуйте, eao197, Вы писали:
E>Да, я считаю, что если какой-то подход для конкретной задачи удобнее и не дороже альтернатив, то его следует использовать. В моем подходе к парсингу конфигов я вижу следующие преимущества:
E>- удобочитаемый и простой формат, который реально легко осваивается админами;
E>- простой механизм парсинга в C++ подобных форматов. Хоть код и получается объемным, но это очень простой код, который так же легко осваивается (не впример XML с DTD и XSD);
E>- это мощный механиз парсинга. Если ты не заметил, то класс для представления тега {if} -- шаблонный. Один и тот же код применяется и для работы с std::string, и для работы с unsigned int. Точно так же его можно использовать для работы с int или более экзотическими форматами типа IPv4 или IPv6. В случае же с разбором DOM-XML потребуется много действий для преобразования значений из строк в конкретные типы данных (те же самые unsigned int, int, IPv4, IPv6).
Это неверно. Никаких действий вообще не потребуется для большинства несложных типов. Для структур типа IPv4/IPv6 придется дописать немножко кода — по одному разу на тип. Вряд ли объем кода специализации темплейта в твоем случае будет меньше.

Здравствуйте, VladD2, Вы писали:
VD>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.
Т.е. у нас есть ASP приложение. Все заинтересованные в конфигурации странички включают config.asp с примерно следующим содержанием:

<% 
dim ConnectionDtring, FileOutputPath, AdminEmail, OutgoingSmtpAddress, OutgoingSmtpPort
ConnectionDtring="DRIVER=..."
FileOutputPath=".."
AdminEmail="admin@site.com"
OutgoingSmtpAddress="192.168.2.24"
OutgoingSmtpPort="25"
%>

Здорово, правда? Кстати, тут есть еще и такое преимущество, что в качестве значений настроек могут выступать не только константы, но и выражения. Что и не снилось ни ини файлам, ни XML .

Здравствуйте, eao197, Вы писали:
E>Это дело вкуса. По мне, так гораздо страшнее было бы работать с конфигом вида:
E>

E><uint_data_class>
E>    <name value="smsg_2::smpp::a_smpp_transmitter_t::connection_state_monitor" />
E>    <priority value="5" />
E>    <font_size value="10" />
        
E>    <if>
E>        <equal_to value="st_not_connected" />
E>        <pixmap value="etc/gemont_1/img/xpm/red_cross_24x16.xpm" />
E>        <bkcolor value="magenta" />
E>    </if>
    
E>    <if>
E>        <equal_to value="st_connected" />
E>        <bkcolor value="blue" />
E>    </if>
E>    <if>
E>        <equal_to value="st_bind" />
E>        <pixmap value="etc/gemont_1/img/xpm/conn_exists_24x16.xpm" />
E>        <bkcolor    value="green" />
E>    </if>
E>    <if>
E>        <equal_to value="st_shutdown" />
E>        <bkcolor    value="yellow" />
E>    </if>
E></uint_data_class>
E>

E>Неужели это выглядит более читабельными и понятным?
Нет. Потому, что надо так:

<uint_data_class name="smsg_2::smpp::a_smpp_transmitter_t::connection_state_monitor" priority="5" font_size="10">
    <if equal_to="st_not_connected" pixmap="etc/gemont_1/img/xpm/red_cross_24x16.xpm" bkcolor="magenta" />
    <if equal_to value="st_connected" bkcolor="blue" />
    <if equal_to value="st_bind" pixmap="etc/gemont_1/img/xpm/conn_exists_24x16.xpm" bkcolor="green" />
    <if equal_to value="st_shutdown" bkcolor="yellow" />
</uint_data_class>

Зачем до абсурда-то доводить?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:


E>>Для меня -- ответ. Я сказал

Автор: eao197
Дата: 20.06.05

, что не понимаю, зачем в конфигах XML Schema, XSLT, XPATH.
S>XML Schema позволяет сделать три вещи:
S>1. Сделать отображение файла в объект класса

Мы все еще говорим про C++?

S>2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации

И потом научить пользователя применять этот редактор.
А затем заниматься сопровождением этого редактора.

S>3. Гарантировать, что подача синтаксически корректного, но неверного семантически конфига приведет к внятному сообщению об ошибке, а не к undefined behavior твоего приложения

Откуда информация об undefined behavior?

S>XPATH позволяет тебе делать такие вещи, как программная модификация конфигов. Ну вот, к примеру, ты написал плагин к чему-то. И тебе надо его в этом чем-то зарегистрировать. В XML ты просто берешь и добавляешь свой тег в соответствующий тег конфига этого чего-то:

Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение.

E>>Хочется спросить по другому: имеет ли право на существование для конфигурационных файлов формат, отличный от XML?
S>Имеет. Но в наше время его применение уже надо обосновывать. Пока что это проще, чем обосновать применение goto, но эта радость ненадолго

Мрачные времена нас ждут. Точно пора в технические писатели переходить

Здравствуйте, Sinclair, Вы писали:

E>>- это мощный механиз парсинга. Если ты не заметил, то класс для представления тега {if} -- шаблонный. Один и тот же код применяется и для работы с std::string, и для работы с unsigned int. Точно так же его можно использовать для работы с int или более экзотическими форматами типа IPv4 или IPv6. В случае же с разбором DOM-XML потребуется много действий для преобразования значений из строк в конкретные типы данных (те же самые unsigned int, int, IPv4, IPv6).
S>Это неверно. Никаких действий вообще не потребуется для большинства несложных типов. Для структур типа IPv4/IPv6 придется дописать немножко кода — по одному разу на тип. Вряд ли объем кода специализации темплейта в твоем случае будет меньше.

В моем случае не придется переделывать код по разбору тегов. А в случае парсинга DOM-представления для каждого нового типа операции извлечения данных из одних и тех же тегов и атрибутов придется переписывать.

Здравствуйте, Sinclair, Вы писали:

E>>Неужели это выглядит более читабельными и понятным?
S>Нет. Потому, что надо так:
S>

S><uint_data_class name="smsg_2::smpp::a_smpp_transmitter_t::connection_state_monitor" priority="5" font_size="10">
S>    <if equal_to="st_not_connected" pixmap="etc/gemont_1/img/xpm/red_cross_24x16.xpm" bkcolor="magenta" />
S>    <if equal_to value="st_connected" bkcolor="blue" />
S>    <if equal_to value="st_bind" pixmap="etc/gemont_1/img/xpm/conn_exists_24x16.xpm" bkcolor="green" />
S>    <if equal_to value="st_shutdown" bkcolor="yellow" />
S></uint_data_class>
S>

S>Зачем до абсурда-то доводить?

А вот потребуется pixmap-у дополнительные параметры указывать, что делать будешь? Теги-то они расширяемее

Здравствуйте, eao197, Вы писали:
E>А вот потребуется pixmap-у дополнительные параметры указывать, что делать будешь? Теги-то они расширяемее
Дык не проблема. Кстати, у Resin, например, большинство параметров настройки могут быть представлены и тегами (тогда будет как раз value=) и атрибутами.

Здравствуйте, eao197, Вы писали:
E>В моем случае не придется переделывать код по разбору тегов. А в случае парсинга DOM-представления для каждого нового типа операции извлечения данных из одних и тех же тегов и атрибутов придется переписывать.
По-моему мы говорим про что-то разное. Для каждого нового атомарного типа нужно определить десериализацию из строки XML. Все. Все остальное доопределяется метаданными. У тебя метаданными выступают шаблоны — что естественно, с учетом отсутствия других метаданных в С++. Такой же подход можно применить к разбору XML. Только объем работ будет чуть поменьше, т.к. значительную часть возьмет на себя внешний парсер.

Здравствуйте, eao197, Вы писали:
E>Мы все еще говорим про C++?
Конечно. Натравливаем на схему соответствующий XSLT и получаем .h + .cpp.
E>Откуда информация об undefined behavior?
Ну как откуда. У тебя же нет отдельного метода проверки конфига на валидность хотя бы на уровне проверки наличия обязательных тегов и немножественности единственных?
E>Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение.
Вопрос остается открытым. Например, сделать резервную копию гораздо проще для одного файла настроек. Кроме того, даже если настройки самого плагина вынесены в его личные файлы, то регистрационная информация вносится в основной конфиг. Нет, я в курсе про то, что приложение может мониторить некоторый путь на предмет внезапного обнаружения подходящих плагинов. Но это далеко не всегда то, чего хочется.
E>Мрачные времена нас ждут. Точно пора в технические писатели переходить
Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Здравствуйте, Andy Panda, Вы писали:

E>>>>> Ну а то, что ты делаешь свой редактор вместо годами и многими проектами отлаженного редактора Scintilla -- это не изготовление малопонятного велосипеда?

Ш>>>> Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.

Ш>>>>

Ш>>>><...>
Ш>>>>

ПК>>>
ПК>>>>

ПК>>>><...>
ПК>>>>

AP>>?

ПК>Гм... Это пример исходников из R#. Не думаю, что исходники обсуждаемого редактора будут сильно отличаться по исполнению...

Не, ну я надеюсь, что после всех слов про ускорение разработки на порядок и пр. бла-бла у Влада просто нет другого выхода, кроме как блеснуть мастерством и заткнуть за пояс Scintillу.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Павел Кузнецов, Вы писали: ...

Поглядел внимательно. Не очень хорошее впечатление. Явно нужен рефакторинг.

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:
VD>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
S>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.

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

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, VladD2, Вы писали:
VD>>>Убедил. Окончательно... Для конфигов нужно изобредать собственные языки на базе синтаксиса разных Кюрлов и т.п.
S>>Не, ну смотря как и что. Кстати, один из самых экзотических (для меня) способов описания конфига — в использовании скриптового языка и инклуда.

ANS>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?

Кстати да. На самом деле такая штука может быть гораздо более удобна. Например, если в качестве языка для конфигов использовать Python или Ruby. На эту тему даже большое обсуждение было: Python vs C#

Автор: WolfHound
Дата: 13.05.05

. Правда там, а так же в Re[21]: Почему нельзя преподавать C#

Автор: VladD2
Дата: 06.03.05

доказывалось, что C# легко заменяет скриптовые языки.

Если продолжать в том же духе, то можно сказать:
— конфиги лучше писать на скриптовых языках;
— вместо скриптовых языков лучше использовать C#.
Следовательно, конфиги лучше писать на C#. Получается, что XML идет лесом

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:
E>>А вот потребуется pixmap-у дополнительные параметры указывать, что делать будешь? Теги-то они расширяемее
S>Дык не проблема. Кстати, у Resin, например, большинство параметров настройки могут быть представлены и тегами (тогда будет как раз value=) и атрибутами.

Т.е. тогда мне нужно будет отдельно разбирать pixmap как атрибут тега if, и как отдельный подтег тега if.
Весело.

Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык?
Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.

Здравствуйте, Павел Кузнецов, Вы писали:

Ш>>Правильно делает. Скачай для интереса исходники Scintill ы и погляди на них даже без микроскопа. Просто просятся на фабрику для вторсырья.
Ш>>

Ш>><...>
Ш>>

ПК>
ПК>

<...>
ПК>

Итого:
public/protected/private
0/3/7 полей
5/2/0 свойств
7/4/2 методов
3/0/0 константы
Вобщемто не много. А теперь посчитай тоже самое для хидера из Scintill'ы

Здравствуйте, eao197, Вы писали:

E>Следовательно, конфиги лучше писать на C#.
Ну, в частности именно такой выбор сделан в WinForms. В отличие от, например, Delphi, где форма описывается внешним ресурсом, в .Net форма сериализуется прямо в код.