Здравствуйте, TK, Вы писали:
TK>За исключением того, что 2005 еще не вышел, что в 2000 использовать тип TEXT можно только в качестве TK>параметра SP (т.е распарсить XML можно только в том случае, если его передали из вне), то все замечательно.
Немного подумал... А что OPENXML, sp_xml_pretpare и переменные типа TEXT/NTEXT уже отменили? Тогда в чем проблема?
VD>>Это точно проще чем писать парсер собственного конфига на TSQL.
TK>хм. ну, покажи пример кода который распарсит мне XML хранящийся в поле типа TEXT...
Почитай хэлп к OPENXML и sp_xml_pretpare. Думаю после этого ты такой пример и сам за пять минут сворганишь.
ЗЫ
Хотя конфиги в БД — это уже полный бред. Чем сама БД то не подходит?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
VD>>Но если сравнить этот класс с Синтилой, то не думаю, что он проиграет. Тут ПК уж явно пересторался.
Ш>Наверное. Но образцом проектирования он тоже не является.
ПК то привел его как бы в доказательство, что лучше чем в Синтиле не будет. Нашел в нем даже того чего там никогда не было (асс и диалоги открывает, и в "потроха" ассоциированных классов "лазит"). В общем, банальная попытка дискредитации.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
VD>>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай. ГВ>Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот.
Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее. Так вот я согласен, что может оказаться, что для какого-то частного случая ХМЛ будет хуже полностью уникального решения. Но надо же понимать, что это как раз и есть исключение, а не правило.
ГВ>А то, что IT кажется, что eao197 "всё усложняет" — очень слабый аргумент.
А мене тоже кажется, что усложняет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Да, я и не подумал, что у людей бывают стль серьезные проблемы.
ГВ>Это и есть основные проблемы. Просто их принято не замечать.
Ну, то есть, проблема в людях. Я то в общем, то эронизировал.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Хорошо, я не совсем корректно сформулировал. Для Януса — не нужны. Но как из этого следует, что они не нужны и для случая, который описал eao197?
VD>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
Цитату, пожалуйста.
VD>>>Я согласен, что возможно в каком-то экзотическом случае самопал окажется лучше и что-то даст. Но тут то совсем другой случай. ГВ>>Хм. А каковы основания для подобного утверждения? Я вот, например, считаю наоборот.
VD>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
Здравствуйте, eao197, Вы писали:
VD>>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
E>Найдешь время, загляни сюда: The Art of Unix Programming: Data File Metaformats, там таких паттернов 6 штук.
Все же XML несколько отличается остальных в лучшую сторону. Хотя бы потому, что его поддержка есть практически во всех языках и средах разработки. Для него даже специальные утилиты пишут. Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
Здравствуйте, Ракот, Вы писали:
Р>Здравствуйте, eao197, Вы писали:
VD>>>Есть панятие паттерна. Ну, эдакого почти стандартного решения той или иной задачи. Так вот на сегодня создание конфигов на базе ХМЛ — это и есть такой паттерн. Раньше таким паттерном были ini-файлы, но задачи усложняются и на сегодня уже ХМЛ обычно выгоднее.
E>>Найдешь время, загляни сюда: The Art of Unix Programming: Data File Metaformats, там таких паттернов 6 штук.
Р>Все же XML несколько отличается остальных в лучшую сторону. Хотя бы потому, что его поддержка есть практически во всех языках и средах разработки. Для него даже специальные утилиты пишут.
Про XML здесь уже много чего сказано. Но еще раз проясню свою позицию, из-за которой я не считаю XML подходящим форматом для конфигурационных файлов (особенно небольших):
— конфиги часто правят люди. Часто не особенно подготовленные и сведующие в XML. Поэтому хочется иметь более читабельный формат, чем XML;
— библиотеки для разбора XML (libxml2, expat, xercer, tinyxml, ...) легко позволяют поднять XML в память в виде DOM-дерева. Но дальше из этого дерева значения все равно нужно преобразовать в какое-то внутреннее представление. И чем сложнее иерархическая структура, чем больше данных нужно преобразовывать из строкового представления в какое-то двоичное (числа, IP-адреса и т.д.), тем более сложным и запутаным в исходном тексте получается обход DOM-дерева (по крайней мере на такой Java-код я в свое время насмотрелся и больше не хочу с такими вещами сталкиваться). Поэтому я считаю, что должна быть библиотека, которая прозрачно преобразует значения из текстового представления конфига во внутрипрограммное представление.
Да, такую библиотеку можно, имхо, и на основе XML-я сделать. Но мне еще хотелось и большей читабельности, чем в XML. Поэтому я и взял за основу синтаксис языка Curl, т.к. в нем были специфицированны и комментарии, и строки, и целые (в двоичном, восьмеричном, десятичном и шестнадцатиричном представлении), и вещественные -- собственно, все что нужно.
Р> Другие же таким похвастаться не могут. Например С++ не имеет поддержку INI формата или Record-Jar.
Здравствуйте, eao197, Вы писали:
E>Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
Да, верно, как раз библиотека [де-]сериализации сможет именно что пропускать неизвестные ей структуры данных. Но это не означает, что мы "десериализуем неизвестный объект", мы просто "относимся к данным неизвестной структуры как к пакету (массиву, списку, ленте, набору...) бинарных данных". Разница тут очевидна: мы не пытаемся создать объект по его описанию, а просто откладываем такие данные и в случае необходимости отправляем их дальше as is.
Возвращаясь к сообщению Влада, замечу, что во-первых, он тебя несколько сбил с толку, а во-вторых, .Net таки да, может создать доселе неизвестный объект по данным, которые приедут по каналу сериализации, но вопрос "А зачем нам десериализовывать неизвестный объект?" остаётся открытым. Кстати, ты на него пусть и не совсем явно, но совершенно верно ответил: "а незачем!", так что, на самом деле, между нами противоречия нет.
Другими словами, техническая возможность для создания типа объекта по его сериализованному описанию есть, но вполне разумно поставить вопросы.
1. Имеет ли смысл выполнять операции по восстановлению внутренней структуры (доселе совершенно не известной получателю!), если единственное, зачем нужен такой объект — это снова упаковать его и отфутболить дальше? Под "восстановлением внутренней структуры" я имею ввиду создание описателя типа, создание экземпляра и т.п., а не размещение пропущенных данных, например, в динамической памяти.
2. Можно ли что-то сделать с восстановленным объектом на сервере, если by design этот объект нужен и известен только клиенту?
Ответы на оба вопроса — "нет".
ГВ>>Тогда одно из двух: либо такому компоненту известно нечто о десериализуемом объекте, E>Естественно что-то знает. Это только для load-balancer-а можно струтуру не знать. Но фишка в том, что промежуточный компонент может не знать всей структуры, а только то, что ему необходимо. И уж тем более ему можно не знать про расширения протокола, которые непосредственно его не касаются.
В точку.
Остальное комментировать не буду, поскольку в принципе со всем согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>- конфиги часто правят люди. Часто не особенно подготовленные и сведующие в XML. Поэтому хочется иметь более читабельный формат, чем XML;
Крайне субъективно. Лично мне XML кажется читабельнее.
E>- библиотеки для разбора XML (libxml2, expat, xercer, tinyxml, ...) легко позволяют поднять XML в память в виде DOM-дерева. Но дальше из этого дерева значения все равно нужно преобразовать в какое-то внутреннее представление. И чем сложнее иерархическая структура, чем больше данных нужно преобразовывать из строкового представления в какое-то двоичное (числа, IP-адреса и т.д.), тем более сложным и запутаным в исходном тексте получается обход DOM-дерева (по крайней мере на такой Java-код я в свое время насмотрелся и больше не хочу с такими вещами сталкиваться). Поэтому я считаю, что должна быть библиотека, которая прозрачно преобразует значения из текстового представления конфига во внутрипрограммное представление.
1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
2) Для дотнета и джавы есть стандартная реализация биндинга xml на классы. В просторечии это означает, что читать XML можно не в универсальный DOM, а в специализированную типизированную структуру.
E>Да, такую библиотеку можно, имхо, и на основе XML-я сделать.
Можно, но лучше воспользоваться готовым.
E> Но мне еще хотелось и большей читабельности, чем в XML.
Т.е. на самом деле это все еще п.1.
Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
Здравствуйте, AndrewVK, Вы писали:
AVK>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
А при чем здесь XPath?
AVK>2) Для дотнета и джавы есть стандартная реализация биндинга xml на классы. В просторечии это означает, что читать XML можно не в универсальный DOM, а в специализированную типизированную структуру.
E>>Да, такую библиотеку можно, имхо, и на основе XML-я сделать.
AVK>Можно, но лучше воспользоваться готовым.
E>> Но мне еще хотелось и большей читабельности, чем в XML.
AVK>Т.е. на самом деле это все еще п.1.
AVK>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
А по поводу субъективизма, то это, вероятно, самый главный аргумент. Ну вот не удобно мне XML-конфиги использовать (ни парсить, ни править, ни администраторов заставлять в них разбираться). Ну не удобно и все. Хоть тресни.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, eao197, Вы писали:
E>>Как раз [де-]сериализацию можно научить распознавать известные ей структуры и пропускать (сохраняя по дороге) неизвестные фрагменты.
ГВ>Да, верно, как раз библиотека [де-]сериализации сможет именно что пропускать неизвестные ей структуры данных. Но это не означает, что мы "десериализуем неизвестный объект", мы просто "относимся к данным неизвестной структуры как к пакету (массиву, списку, ленте, набору...) бинарных данных". Разница тут очевидна: мы не пытаемся создать объект по его описанию, а просто откладываем такие данные и в случае необходимости отправляем их дальше as is.
Ну не совсем так. Пусть, скажем есть иерархия:
class compression_mode_t { ... };
class zip_compression_t : public compression_mode_t { ... };
class zip_compression_with_desired_level_t : public zip_compression_t { ... };
Сериализуется объект zip_compression_with_desired_level_t, а десериализатор про него не знает. Но знает про zip_compression_t. Поэтому десериализатор может работать с составляющей из zip_compression_t, не зная даже про zip_compression_with_desired_level_t.
ГВ>Другими словами, техническая возможность для создания типа объекта по его сериализованному описанию есть, но вполне разумно поставить вопросы. ГВ>1. Имеет ли смысл выполнять операции по восстановлению внутренней структуры (доселе совершенно не известной получателю!), если единственное, зачем нужен такой объект — это снова упаковать его и отфутболить дальше? Под "восстановлением внутренней структуры" я имею ввиду создание описателя типа, создание экземпляра и т.п., а не размещение пропущенных данных, например, в динамической памяти.
Здесь я не был бы так категоричен. См. пример выше. В таких ситуациях структура объекта zip_compression_with_desired_level_t может быть как угодно большой и сложной, но мы сможем использовать из нее ту часть, которая относится к zip_compression_t. И именно такая иерархия (когда zip_compression_with... производится от zip_compression_t, а не от compression_mode_t) показывает, что идет "неограничивающее" расширение объекта, когда что-то новое, полезное добавляется, но не нарушается совместимость. Если же хочется добавить что-то, про что остальные знать не должны совсем, можно унаследоваться непосредственно от compression_mode_t. И тогда я согласен с тобой, ответ на этот вопрос "нет".
ГВ>Остальное комментировать не буду, поскольку в принципе со всем согласен.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
E>А при чем здесь XPath?
При его помощи можно делать выборки конкретных вещей, не бегая вручную по DOM. Пример тебе уже, кажется, приводили.
AVK>>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
E>Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
http://xml.apache.org/ — одна из наиболее навороченных реализаций приличного количества
XML-технологий. И на С++ в том числе. И xml binding для C++ тоже наверняка существует. Вот, сходу нашел http://tech-know-ware.com/lmx/
E>А по поводу субъективизма, то это, вероятно, самый главный аргумент.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
AVK>>>1) XPath на сегодня умеют очень большое количество парсеров. Реализовывать аналог самостоятельно ты закопаешься.
E>>А при чем здесь XPath?
AVK>При его помощи можно делать выборки конкретных вещей, не бегая вручную по DOM. Пример тебе уже, кажется, приводили.
Т.е. ты предлагаешь хранить в памяти весь DOM и по мере надобности дергать оттуда значения? В таком случае, имхо, просядет производительность.
А если извлекать из DOM все значения сразу, то, имхо, это будет то же самое, что и обход (особенно, если в XML есть списковые структуры), но только с помощью XPath.
AVK>>>Итого — единственный аргумент субъективен. Супротив сонма технологий и инструментария вокруг XML.
E>>Сомн технологий и инструментария -- это все вокруг Java и C#, о чем ты сам и сказал (это я в смысле биндинга XML на типизированные структуры). В C++ мы располагаем только базовым набором инструментов вокруг которого и приходится свои обвязки делать.
AVK>http://xml.apache.org/ — одна из наиболее навороченных реализаций приличного количества AVK>XML-технологий. И на С++ в том числе. И xml binding для C++ тоже наверняка существует.
AVK> Вот, сходу нашел http://tech-know-ware.com/lmx/
(еще и платный )
Можно еще и gSOAP применить. Только у него другая идеология, от C++ структуры к XML.
E>>А по поводу субъективизма, то это, вероятно, самый главный аргумент.
AVK>Так и я о том же.
Так я и ни когда не скрывал
Более того, вопрос о том, имеют ли право на жизнь другие форматы конфигурационных файлов, кроме XML для меня остается открытым.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
V>>Тоже не панацея. Если у меня свой контрол, куда мне схему подавать для валидации, и ведь ее еще делать надо.
VD>В Авалоне все контролы "свои". Там ничего встроенного нет. Все живет по одинковой схеме.
Меня интересует момент — как мне проверить валидность моего XAML в отсутствии схемы на "свои" контролы?
Может, я там значения несуществующих св-в выставляю для какого-то контрола.
Здравствуйте, eao197, Вы писали:
VD>>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
E>Цитату, пожалуйста.
Здравствуйте, vdimas, Вы писали:
V>Меня интересует момент — как мне проверить валидность моего XAML в отсутствии схемы на "свои" контролы?
V>Может, я там значения несуществующих св-в выставляю для какого-то контрола.
Я копл не глубоко, но вроде как схемы генерируются. Да и компилятор есть. Так что все проверяется.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, eao197, Вы писали:
VD>>>А он про свой случай вообще ничего не говорит. Он свой велосипед как панацею преподнсоит. Ну, если не как панацею, то как универсальное решение.
E>>Цитату, пожалуйста.
VD>Re[20]: Формат конфигов
Во-первых, ты нарушаешь хронологию событий. Пост, на который ты дал ссылку был сделан уже после того, как я попросил тебя дать цитату.
Во-вторых, где там слова "панацея", "универсальность" или даже "принципиально лучше"? Посмотри внимательно:
Но еще раз проясню свою позицию, из-за которой я не считаю XML подходящим форматом для конфигурационных файлов (особенно небольших):
Вот и все. На гегемонию XML я не покушался. Просто я считаю, что в данной конкретной области, на мой взгляд, XML не удобен. И поэтому применяю вместо него свой велосипед (уже четыре года).
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
[...] S>XML Schema позволяет сделать три вещи:
[...] S>2. Сделать универсальный редактор конфига, который поддерживает code completion и подсказки валидации
Имеется в виду готовый типа XML Spy? Или в своей программе.
А не могли мы Вы поделиться опытом как Вы XML Schema деплоите (в случае внешнего редактора).
Я тут с этим разбираюсь и это кажется интересным вопросом.
Use case 1 — config file location is under application root:
<app root>/
<app data>/
1.xml
2.xml
schema.xsd
В 1.xml — все в порядке, нужен относительный путь:
...
uri:schemaLocation="urn:... ..\schema.xsd"
Use case 2 — config file location is not under application root:
В 1.xml — что писать в schemaLocation? Полный путь? А если приложение xcopy deployable и было перемещено? Это разрешимо — но интересно как вы делаете. Всегда копируете schema in the root of the data dir?
Здравствуйте, eao197, Вы писали:
E>Т.е. ты предлагаешь хранить в памяти весь DOM и по мере надобности дергать оттуда значения? В таком случае, имхо, просядет производительность.
На конфигах? Не смешите мои тапочки.
E>А если извлекать из DOM все значения сразу, то, имхо, это будет то же самое, что и обход (особенно, если в XML есть списковые структуры), но только с помощью XPath.
Не то же самое. На XPath получается значительно короче, и, что характерно, по большей части декларативно. Опять же на дотнете можно так:
Надеюсь ты уже понимаешь, что реализация Config.LoadData это один, макcимум два экрана кода, причем один раз.
AVK>> Вот, сходу нашел http://tech-know-ware.com/lmx/ E>(еще и платный )
Думается, если поискать, то и бесплатный найти можно. Впрочем платный в любом случае обойдется дешевле, нежели написание и поддержка своего парсера самостоятельно.
E>Более того, вопрос о том, имеют ли право на жизнь другие форматы конфигурационных файлов, кроме XML для меня остается открытым.
Все зависит от того насколько лояльно относится твой работодатель/заказчик к удовлетворению твоих эстетичеких чувств за свой (работодателя) счет.
