Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Это так, но, Андрей, я придерживаюсь чуть другой точки зрения. Если мне что-то не нравиться, что я могу либо с этим смириться, либо сделать и развивать то, что мне нравится.
AVK>Ради бога. Только тогда так и говори — я нарисовал свой парсер исключительно из личных предпочтений и не ищи фатальных недостатков в XML.
Так ведь я в этом контексте и старался говорить. Именно исходя из своего взгляда на то, как должен выглядеть конфигурационный файл, я и сделал свой парсер. А дальше только отстаивал точку зрения, что для конфигов у XML есть реальные альтернативы, пусть и в виде собственных велосипедов. Вот, собственно, и все.
AVK>Никакого везения. Я сам выбирал что мне делать.
Вот и я выбрал для себя не связываться с XML, если этого можно избежать. Пока полет нормальный.
E>>Имхо, ты и предлагаешь, см. ниже.
AVK>Вот так чтобы прям везде? ИМХО ты видимо неверно меня понял.
Вероятно.
AVK>Это есть, скажем так, некорректные приемы ведения дискуссии.
Ok. Приношу извинения, если что-то сказал не так.
Я давно предлагал эту тему закрыть.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто.
Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
ПК> В другом случае (в javascript) в готовом виде были доступны только регулярные выражения, которыми XML, очевидно, не парсится, т.к. не является регулярной грамматикой.
Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
ПК> В общем, вряд ли верно говорить о безусловном превосходстве XML в качестве языка конфигурационных файлов без анализа конкретных use cases.
Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
E>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал.
Да, была привычка выпускать продукты до утверждения стандарта. Или утверждать стандарт после выпуска продукта. Но сейчас xml и схемы приведены к единому знаменателю. Непонятно откуда это утверждение. E>Ну и насчет редакторов можно поспорить -- хорошо, когда они есть.
У меня клиенты просто писают кипятком, когда открывают IE и у них показывается строчка что сделано неправильно. Схему они не редактируют, а понять сам xml и как его редактировать, чрезвычайно легко. Чем я и пользуюсь. (а вот такую вещь как в статье, я за любые коврижки делать не буду. Оно интересна только в познавательном смысле).
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Кроме того, если берем серьезных XML парсер, скажем libxml2, expat, xerces, то можно наткнуться на несовместимость, про которые я уже писал. GZ>Да, была привычка выпускать продукты до утверждения стандарта. Или утверждать стандарт после выпуска продукта. Но сейчас xml и схемы приведены к единому знаменателю. Непонятно откуда это утверждение.
Я вообще-то говорил об API библиотек. Не скажу точно за libxml2, а вот с OpenSSL частенько раньше бывали грабли из-за того, что есть две ветки OpenSSL: 0.9.6* и 0.9.7*. Причем в 0.9.7* есть функции, которых нет в 0.9.6*. Вот если их задействовать, то при попадании на машину, где 0.9.7 отказываются ставить принципиально, приходится либо переубеждать тамошних админов, либо переписывать свой код, либо ставить 0.9.7 втихаря в свой каталог
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Andrei N.Sobchuck wrote:
> Подходит под определении простого конфига. > > C>Для каких-либо слишком извращенных кастомных конфигов. > > Или наоборот из желания сделать конфиги более простыми > ЗЫ. Имхо в .ini 2 уровня.
Здравствуйте, AndrewVK, Вы писали:
ПК>>Use case был такой: ПК>>
ПК>>наш support по телефону диктует пользователям как править наш (а зачастую и не наш) config file
AVK>1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
Представляю сценарий:
— Алё, служба поддержки? У меня приложение не инсталлируется.
. . .
— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
— У меня вообще ничего не инсталлируется, утилита тоже.
— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
Упс.
Или еще:
— Алё, служба поддержки? У меня приложение не запускается.
. . .
— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
— Утилита тоже не запускается; тоже выдает какую-то странную ошибку XYZ.
— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
Упс.
В общем, "обязательно" может оказаться "желательно". А если формат файла простой, то и вовсе "по желанию".
AVK> 2) Если же их редактирует админ хотя бы, то современный админ с тем что такое XML обычно знаком.
Нет, не современный. Нет, не админ. Нет, не знаком.
ПК>> Соответственно, в этом контексте можно видеть, что предполагать наличие привычки править "руками" XML у пользователей продукта не вполне разумно.
AVK> ПРавить руками пользователям любой текстовый фоайл вобще совершенно неразумно.
Зависит от обстоятельств. В реестр или еще куда просить пользователей лазить тоже "неразумно", но иногда приходится.
P.S. А все ради чего? "Чтоб был XML" Прошу понять меня правильно, я за XML в определенных случаях, даже на прошлой работе поддерживал перевод конфигурационных файлов игрушки на XML, т.к., имхо, дополнительные возможности XML (например, XPath) там были полезны. Вопрос в том, всегда ли плюсы от использования XML в качестве формата конфигурационных файлов перевешивают минусы...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто.
AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
В том случае из MsSql вызывался "голый" JavaScript server-side.
ПК>> В другом случае (в javascript) в готовом виде были доступны только регулярные выражения, которыми XML, очевидно, не парсится, т.к. не является регулярной грамматикой.
AVK>Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
А если JavaScript используется не в браузере, а сам по себе, в качестве скриптового языка в составе приложения?
ПК>> В общем, вряд ли верно говорить о безусловном превосходстве XML в качестве языка конфигурационных файлов без анализа конкретных use cases.
AVK>Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
Ну, если отметать чужие use cases как "несущественные", то конечно...
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто. AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, VladD2, Вы писали:
VD>Да, хорошая демонстрация очередного заката солнца вручную. Ради хохмы приведу аналог вот этого:
[...] VD>на Шарпе:
[...]
Вся проблема в том, что как правило, закодировать саму сериализацию куда как проще, чем определиться с тем, что именно хранить, зачем хранить и как и когда читать/писать. А закодировано это в три строки или в десять — ну никакой разницы: ни в разработке, ни в сопровождении.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
P.S.
> ПК>>Не всегда парсить XML легко. Например, из SQL это делается вовсе непросто. > > AVK>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю. > > В том случае из MsSql вызывался "голый" JavaScript server-side.
В том смысле, что этот самый JavaScript, помимо прочего, возвращал строку с XML, из которой нужно было "выудить" некоторую информацию. Почему-то у нас это "элементарно" сделать не вышло.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>Из MSSQL и Oracle это сделать элементарно. Про остальные сервера не знаю.
ПК>В том случае из MsSql вызывался "голый" JavaScript server-side.
Ну вот из MSSQL отпарсить XML нет никаких проблем и не надо никакой JavaScript звать.
AVK>>Да ну? А ты не слышал о том что, к примеру, начиная с IE4 в состав входит MSXML parser? В Mozilla/Firefox есть аналог. Google Maps думаешь как, по твоему, работает?
ПК>А если JavaScript используется не в браузере, а сам по себе, в качестве скриптового языка в составе приложения?
Еще проще.
AVK>>Возможно. Но за последние лет 7 я такой ситуации не встречал на практике ни разу.
ПК>Ну, если отметать чужие use cases как "несущественные", то конечно...
Я не отметаю, я пытаюсь услышать реальные причины. Пока ничего круче личных предпочтений я не услышал.
Здравствуйте, TK, Вы писали:
TK>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В том смысле, что этот самый JavaScript, помимо прочего, возвращал строку с XML, из которой нужно было "выудить" некоторую информацию. Почему-то у нас это "элементарно" сделать не вышло.
Здравствуйте, Павел Кузнецов, Вы писали:
AVK>>1) Файлы, редактируемые пользователем, обязательно должны редактироваться специальной утилитой.
ПК>Представляю сценарий: ПК>
ПК>— Алё, служба поддержки? У меня приложение не инсталлируется.
ПК>. . .
ПК>— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
ПК>— У меня вообще ничего не инсталлируется, утилита тоже.
ПК>— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
ПК>Упс.
ПК>Или еще: ПК>
ПК>— Алё, служба поддержки? У меня приложение не запускается.
ПК>. . .
ПК>— Запустите утилиту XXX, и замените значение поля X в категории "Log" на Y.
ПК>— Утилита тоже не запускается; тоже выдает какую-то странную ошибку XYZ.
ПК>— Тогда найдите файл в пути ~/Library/Preferences/MetaCommunications/Application/config.xml, и найдите в нем секцию "Log", и замените в ней значение поля X на Y.
ПК>Упс.
А казалось бы, при чем здесь XML?
ПК>В общем, "обязательно" может оказаться "желательно". А если формат файла простой, то и вовсе "по желанию".
Можно определение понятия "простой формат"? Так чтобы было понятно, чем самопальный велосипед проще XML.
AVK>> 2) Если же их редактирует админ хотя бы, то современный админ с тем что такое XML обычно знаком.
ПК>Нет, не современный. Нет, не админ. Нет, не знаком.
Тогда см. выше.
AVK>> ПРавить руками пользователям любой текстовый фоайл вобще совершенно неразумно.
ПК>Зависит от обстоятельств.
Не зависит. Если конечно не принимать за таковые лень разработчика.
ПК>P.S. А все ради чего? "Чтоб был XML"
Нет, ради стандарта. Вот к примеру современная схема управления автомобилем далека от совершенства. Однако почему то никому не приходит в голову в серийном автомобиле от нее отходить. Здесь то же самое. Появится новый стандарт, который поддержит заметное количество производителей, можно будет обсудить преимущество того и другого. А вот сравнивать самопальный формат и индустриальный можно только при очень особых обстоятельствах.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, TK, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
AVK>Мы еще про конфиги говорим?
Guru считают что конфиги надо читать исключительно через SQL Server 2000?
Здравствуйте, AndrewVK, Вы писали:
TK>>Точно, давай распарсим в SQL Server 2000 килобайт 100 XML-я (XML само собой лежит в табличке) в хранимой процедуре или в функции. Не набросаешь примерный код на T-SQL?
AVK>Мы еще про конфиги говорим?
Не, про то, что "из SQL это делается вовсе непросто"
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Но сейчас xml и схемы приведены к единому знаменателю. Непонятно откуда это утверждение.
Прошу понять меня правильно, я за XML в определенных случаях, даже на прошлой работе поддерживал перевод конфигурационных файлов игрушки на XML, т.к., имхо, дополнительные возможности XML (например, XPath) там были полезны. Вопрос в том, всегда ли плюсы от использования XML в качестве формата конфигурационных файлов перевешивают минусы...
