Здравствуйте, eao197, Вы писали: E>Т.е. тогда мне нужно будет отдельно разбирать pixmap как атрибут тега if, и как отдельный подтег тега if. E>Весело.
В С# тебе ничего не надо будет разбирать. Все сделает XMLSerializer и атрибуты.
В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали: E>>Мы все еще говорим про C++? S>Конечно. Натравливаем на схему соответствующий XSLT и получаем .h + .cpp.
Это интересно. Нужно будет покурить.
Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах.
E>>Откуда информация об undefined behavior? S>Ну как откуда. У тебя же нет отдельного метода проверки конфига на валидность хотя бы на уровне проверки наличия обязательных тегов и немножественности единственных?
-- Ты суслика видишь?
-- Нет.
-- И я нет. А ведь он есть!
((C) к/ф "ДМБ")
Если этих методов не видно, то это не значит, что такой проверки нет.
Ведь в приведенном мной фрагменте есть только классы, которые описывают тег. И с подачи Влада почему-то все стали думать, что это парсер и есть . Все приведенные мной классы тегов являются, с одной стороны, своеобразным описанием граматики (что-то вроде DTD), а с другой стороны -- они используются для хранения разобранных значений.
А уже реальный вызов парсера (с большинством проверок, как синтаксических, так и семантических) вот он:
А про обязательность тегов и пр. нужно всего лишь посмотреть на конструктор, например, tag_if_t (оригинал исходников вот здесь: Re[4]: Has C# lost its point?
tag_if_t(
// Это имя тега. Оно не задается жестко здесь, т.к. будет задано родительским тегом.const char * name,
// Признак того, должен ли тег быть обязательным. Так же задается родительским тегом.bool is_mandatory )
// Передаем параметры базовому типу.
: base_type_t( name, is_mandatory,
// Вот этот true говорит, что тег {if} должен быть определен всего один раз.true )
// Тег {op} инициализируется собственным конструктором, в котором указывается, что
// он должен быть обязательным.
, m_op( self_tag() )
// У остальных тегов последний параметр равен false, значит они не обязательны.
, m_pixmap( self_tag(), "pixmap", false )
, m_bkcolor( self_tag(), "bkcolor", false )
, m_sound( self_tag(), "sound", false )
, m_log_event( self_tag(), "log_event", false )
, m_launch_external( self_tag(), "launch_external", false )
{
// Вот здесь еще один интересный момент. Для тега {bkcolor} устанавливаются
// ограничения -- он может принимать только одно из фиксированного набора значений.
fill_color_constraint( m_bkcolor_constraint );
m_bkcolor.set_constraint( &m_bkcolor_constraint );
}
По умолчанию, однажды распарсенный тег не должен встречаться в конфиге еще раз. Поэтому, если, например, тег {bkcolor} будет указан два раза, произойдет диагностирование ошибки. Но, если такая семантика необходима, то можно переопределить метод tag_t::on_finish и сбросить в нем признак определенности тега.
Так что все необходимые проверки в парсер включены.
E>>Вместо всей этой байды проще разрешить плагинам сохранять свои конфигурации в своих файлах и своих подкаталогах. Очень простое и удобноее решение. S>Вопрос остается открытым. Например, сделать резервную копию гораздо проще для одного файла настроек.
Да уж, аргумент
Я тут пытался привести аргументы, что таскание за собой сторонних библиотек типа libxml2 или xerces на разные платформы может быть геморройно, но его в серьез не принимали. А тут оказывается, что сделать резервное копирование одного файла на порядок проще, чем резервное копирование подкаталога с конфигурационными файлами.
E>>Мрачные времена нас ждут. Точно пора в технические писатели переходить S>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя.
Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>В С# тебе ничего не надо будет разбирать. Все сделает XMLSerializer и атрибуты. S>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык? S>Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.
Здравствуйте, Sinclair, Вы писали: ANS>>Кстати, да. Зачем изобретать свой чудо формат, если можно прикрутить некий скриптовый язык? S>Для того, чтобы применять валидацию, выборочную модификацию, и автоматическое построение GUI.
А почему этим не пользуются
S>>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
E>А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)?
Хм. http://rsdn.ru/?article/xml/xmlcpp.xml
Здравствуйте, eao197, Вы писали:
E>Это интересно. Нужно будет покурить. E>Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах.
А чем они будут являться? E>Если этих методов не видно, то это не значит, что такой проверки нет. E>Так что все необходимые проверки в парсер включены.
Ок, хорошо. E>Да уж, аргумент E>Я тут пытался привести аргументы, что таскание за собой сторонних библиотек типа libxml2 или xerces на разные платформы может быть геморройно, но его в серьез не принимали.
Конечно не принимали. Библиотеки таскаешь ты. Даже если тебе очень-очень не хочется выполнить статическую линковку, все библиотеки просто включены раз и навсегда в дистрибутив.
А плагины собственно и сделаны разными разработчиками. И гарантировать, что все их конфигурации будут в рамках одного подкаталога в общем случае не выйдет. В итоге, резервно копировать придется много хаотично разбросанных файлов, и уверенности в окончательности не будет. К тому же, даже если с этим согласиться, все равно как минимум регистрация плагина в конфиге основного приложения является весьма желательной. С точки зрения этой задачи неважно, где хранятся настройки самого плагина. E>А тут оказывается, что сделать резервное копирование одного файла на порядок проще, чем резервное копирование подкаталога с конфигурационными файлами.
S>>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя. E>Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению
Почему же? Дают. Нужно только внятно обосновать преимущества по сравнению с существующим. Я вот пока так и не уловил, чем конкретно провинился XML и почему синтаксис CSS тебе нравится больше.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Это интересно. Нужно будет покурить. E>>Правда не понятно, что делать, если названия тегов в конфигах не являются названиями атрибутов в классах. S>А чем они будут являться?
Ну например, вместо m_file_name удобнее бывает использовать pixmap-file-name или .pixmap.
Кроме того бывают случаи, когда после рефакторинга структура класса с конфигурацией не совпадает со структурой тегов в конфигурационном файле.
S>А плагины собственно и сделаны разными разработчиками. И гарантировать, что все их конфигурации будут в рамках одного подкаталога в общем случае не выйдет.
Это почему? Передавай плагинам имя каталога в котором им нужно работать и все.
S>В итоге, резервно копировать придется много хаотично разбросанных файлов, и уверенности в окончательности не будет. К тому же, даже если с этим согласиться, все равно как минимум регистрация плагина в конфиге основного приложения является весьма желательной. С точки зрения этой задачи неважно, где хранятся настройки самого плагина.
Не знаю на счет плагинов, но мы сейчас используем комплексы, которые в динамике собираются из нескольких DLL (в принципе, их можно рассматривать как плагины). Так вот каждая DLL хранит свои конфиги в отдельном подкаталоге общего каталога etc. Каталог etc находится под контролем svn. В такой архитектуре очень легко средствами svn копировать конфигурацию отдельной DLL (плагина) из одной инсталляции в другую. А если конкретный подкаталог вообще спроецирован через svn:externals, то тогда изменения конфигов в одной ветке репозитория автоматически распространяется на все инсталляции. Очень удобно.
S>>>Не вижу никакого повода для мрака. Судьба строителя велосипедов всегда была тяжела. Обосновывать необходимость своего велосипеда — это первая обязанность велосипедостроителя. E>>Так ведь я не про то, что обосновать необходимость велосипеда все сложнее и сложнее становится. А про то, что этого вообще делать не дают, по определению S>Почему же? Дают. Нужно только внятно обосновать преимущества по сравнению с существующим. Я вот пока так и не уловил, чем конкретно провинился XML и почему синтаксис CSS тебе нравится больше.
Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
я вряд ли смогу. Кроме того, это синтаксис не CSS, а Curl.
Если говорить про XML, то я так и не могу понять, зачем мне использовать его для ведения конфигов, особенно в системах, которые вообще в XML не нуждаются. Просто, чтоб был XML?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>>>В C++ ты напишешь шаблонный код, который точно так же десериализует XML, как и твой формат.
E>>А есть уже готовые такие шаблоны для C++ (ну кроме boost::serialization)? S>Хм. http://rsdn.ru/?article/xml/xmlcpp.xml
Ну, его еще от MSXML отвязать нужно. И что в результате получится? Проверенное промышленное решение? Или такой же велосипед, как у меня (но для XML-ного синтаксиса)?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Гуй это проперти-грид в Янусе?
В частности. А вообще — способов масса. Главное, что вместе с форматом данных конфига есть и формат метаданных.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: ANS>>Гуй это проперти-грид в Янусе? S>В частности. А вообще — способов масса. Главное, что вместе с форматом данных конфига есть и формат метаданных.
То есть, если я добавлю в конфиг свой тег, то в проперти-гриде он тоже появится?
А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Зачем? Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
Здравствуйте, eao197, Вы писали:
E>>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
Здравствуйте, AndrewVK, Вы писали:
ANS>>А нафига в Янусе вообще конфиг в XML? Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
AVK>Зачем?
Лишняя сущность. Вопросов бы не было, если бы в этом конфиге хранилась внешняя (по отношению к приложению) информация. Типа, параметры конекта к БД, прокси. Но параметры БД это у вас просто каталог, поркси можно у винды спрашивать.
Текстовый конфиг же для внутренних параметров удобен тем, что для него редактор писать не нужно. А коль у вас редактор есть, то не нужен и текстовый конфиг.
AVK>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
Решается через профили.
Кстати, а что там меняется кроме параметров прокси?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Лишняя сущность. Вопросов бы не было, если бы в этом конфиге хранилась внешняя (по отношению к приложению) информация. Типа, параметры конекта к БД, прокси.
А прокси там и хранится.
ANS> Но параметры БД это у вас просто каталог, поркси можно у винды спрашивать.
Как оказывается неможно. Думаешь ручную настройку добавили от нефиг делать?
ANS>Текстовый конфиг же для внутренних параметров удобен тем, что для него редактор писать не нужно. А коль у вас редактор есть, то не нужен и текстовый конфиг.
Нужен. Потому что и редактор, бывает, глючит, и отлаживаться надо, и вероятность того что он слетит и потом не восстановишь меньше.
AVK>>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
ANS>Решается через профили.
С отдельным конфигом намного проще.
ANS>Кстати, а что там меняется кроме параметров прокси?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, eao197, Вы писали:
E>>>>Если говорить про синтаксис -- то это из области субъективных впечатлений. И добавить что-то к вот этому флейму: Чем так уж хорош XML?
я вряд ли смогу. Кроме того, это синтаксис не CSS, а Curl.
ANS>>>Интересно, а почему CSS не XML?
E>>Не понял вопроса.
ANS>Синтаксис в CSS почему не XML?
Так ведь это не у меня нужно спрашивать, а у авторов CSS
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
AVK>>>Базу к примеру я таскаю с работы домой и обратно, а вот конфиг таскать не надо, настройки в нем разные.
ANS>>Решается через профили.
AVK>С отдельным конфигом намного проще.
ANS>>Кстати, а что там меняется кроме параметров прокси?
AVK>Открой, посмотри. Много чего.
Я понимаю Мне интересно, что у тебя разного в офисе и дома? Может и я захочу.
ЗЫ. А список отправленных постов в Янусе как посмотреть?
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>То есть, если я добавлю в конфиг свой тег, то в проперти-гриде он тоже появится?
Нет. Что, в общем-то, правильно. Но внесение соответствующих изменений в класс конфига автоматически подхватится как UI, так и парсером конфига. ANS>А нафига в Янусе вообще конфиг в XML?
Так удобнее. ANS>Держали б его в БД. Всё равно там нельзя отдельно хранить БД от конфигов.
Можно.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Все приведенные мной классы тегов являются, с одной стороны, своеобразным описанием граматики (что-то вроде DTD), а с другой стороны -- они используются для хранения разобранных значений.
