Особенности архитектуры:
DOM основан на XmlElement и может использоваться везде вместо XML, например в XML сериализации (такой план).
CSS поддерживает не только CSS селекторы, но и XPath.
В качестве скриптового движка будет использоваться Jint.
CSS Rule это два скомпилированных на лету DynamicMethod-а. Первый — проверяет условия, второй — модифицирует DOM. В мобильной версии (когда руки дойдут), будет два Jint-метода, если в .Net CF так и не появится компилятор.
Особенности плана работ:
Полезность проекта на любой стадии разработки приоритетна. После третьей стадии проект должен стать конкурентом HtmlAgilityPack.
Потенциальная возможность параллельной разработки зависимых модулей.
MONO поддерживать собираемся.
В данный момент мы заняты тем что:
Настраиваем рабочее окружение. Пока остановили выбор на VS2010 (C#/.Net 4.0), RedMine, Mercurial, xUnit (TestDriven.Net).
Пишем первый набросок парсера HTML, читаем спецификации. Умнеем.
По мере возможности, стандартизируем классы касающиеся HTML DOM и CSS Rules.
Ну и если кто-то ещё захочет участвовать, ничего кроме радости это не вызовет
XmlNodeReader — есть XmlReader, реализовать аналогичный, который обходит ту или иную реализацию дерева вообще не проблема.
Если смотреть на XmlDocument vs XDocument и прочие, то XmlDocument безусловно много ближе по своей сути, т.к. он реализует W3C DOM Level 2 Core. Например XmlAttribute есть XmlNode, в то время как XAttribute — нет. За одно это этого в принципе достаточно, что бы к чертям выкинуть XDocument.
Впрочем, лично я пока ни к одному из них не склонился. Работы хватает пока без этого.
Здравствуйте, AndrewVK, Вы писали:
A>> Концертация в объекты и обратно XML сериализацией — сценарий, а то что ты описал личное мнение. Я отдаю предпочтение не абстрактной крутости, а удобству интеграции. AVK>Ну вот и поясни тогда, чем XmlElement лучше XElement. На конкретных примерах.
XmlElement, наследник XmlNode, можно передать в конструктор XmlNodeReader. Следовательно, для конвертации из DOM в дерево типизированных объектов и обратно, из объектов в DOM, можно использовать XmlSerializer. Кроме того, хотя XmlElement и класс, он фактически не содержит непереопределяемых реализаций и не навязывает их.
XElement/XNode напротив содержит много непереопределяемых реализаций. Простая задача, предоставление механизма оповещения об изменении атрибутов, не представляется простой в реализации.
Здравствуйте, adontz, Вы писали:
A>XmlElement, наследник XmlNode, можно передать в конструктор XmlNodeReader.
Аналогичный ридер есть и для XElement
A>Кроме того, хотя XmlElement и класс, он фактически не содержит непереопределяемых реализаций и не навязывает их.
XElement намного более легковесен.
A>XElement/XNode напротив содержит много непереопределяемых реализаций.
Ты что то путаешь.
P.S. Написание собственного XmlReader для собственной структуры — совсем несложная задача.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
A>> DOM основан на XmlElement и может использоваться везде вместо XML, например в XML сериализации (такой план). AVK>Почему не XElement?
А в чём плюсы по сравнению с XmlElement исходя из сценариаев использования?
A>> CSS Rule это два скомпилированных на лету DynamicMethod-а. AVK>Компиляция должна быть опциональной, иначе на ряде сценариев получишь немаленькие тормоза.
Вариант с Jint-скриптом я описал, а без результатов профайлинга оптимизировать нет смысла.
Здравствуйте, AndrewVK, Вы писали:
A>>А в чём плюсы по сравнению с XmlElement исходя из сценариаев использования? AVK>Легче, удобнее, лучше продуман интерфейс.
Это не сценарий использования. Концертация в объекты и обратно XML сериализацией — сценарий, а то что ты описал личное мнение. Я отдаю предпочтение не абстрактной крутости, а удобству интеграции.
Здравствуйте, adontz, Вы писали:
AVK>>Легче, удобнее, лучше продуман интерфейс.
A>Это не сценарий использования.
Естественно не сценарий.
A> Концертация в объекты и обратно XML сериализацией — сценарий, а то что ты описал личное мнение. Я отдаю предпочтение не абстрактной крутости, а удобству интеграции.
Ну вот и поясни тогда, чем XmlElement лучше XElement. На конкретных примерах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
A>>XElement/XNode напротив содержит много непереопределяемых реализаций. AVK>Ты что то путаешь.
XAttribute.Value — зачем далеко ходить.
Здравствуйте, AndrewVK, Вы писали:
F>>Если смотреть на XmlDocument vs XDocument и прочие, то XmlDocument безусловно много ближе по своей сути AVK>Ближе к чему?
К W3C DOM.
F>>, т.к. он реализует W3C DOM Level 2 Core AVK>Который сам по себе — уродство то еще.
Вопрос спорный. Каким бы он не был — его интерфейс является стандартным и должен быть реализован.
F>>Например XmlAttribute есть XmlNode, в то время как XAttribute — нет. AVK>И чем это плохо?
Тем, что аттрибуты в W3C DOM устроены не так.
Здравствуйте, adontz, Вы писали:
A>О, а я даже не обратил внимания. Очень здорово.
Имеет смысл ориентироваться на Level 3 — сходу впишется он или нет — пока что тоже не знаю.
Здравствуйте, AndrewVK, Вы писали:
AVK>P.S. Написание собственного XmlReader для собственной структуры — совсем несложная задача.
Ну, мы для HTML писали свой reader и пользовались своими "совсем легковесными объектами" для формирования структуры. Легковесность еще в том, что известные таги и аттрибуты в этой модели представлены кодами enum — гораздо быстрее идет оперирование. И там действительно ничего сложного, разработка всей модели — 3 дня максимум.
Здравствуйте, vdimas, Вы писали:
V>Легковесность еще в том, что известные таги и аттрибуты в этой модели представлены кодами enum — гораздо быстрее идет оперирование.
Мне как то для одной узкой задачи понадобилось ускорить XML DOM (XElement тогда еще не было). Просто переписывание узлов без каких либо изысков ускорило чтение дерева раз в 20.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне как то для одной узкой задачи понадобилось ускорить XML DOM (XElement тогда еще не было). Просто переписывание узлов без каких либо изысков ускорило чтение дерева раз в 20.
Да, похожий порядок. Конкретно ускорение чтения не замерял, но общее время, где было чтение + обработка "нашего DOM" HTML, ускорилось 30-50 раз (чем больше страница, тем больше разница).
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Visor2004, Вы писали:
A>>>Нарисовались набросок архитектуры и план работ V>>А в качестве рендерера, что собираетесь использовать?
A>OpenGL
Я в следующем феврале начинаю писать рендерер заточенный для отрисовки UI в одном игровом проекте. UI будет описываться в виде xml, наподобие xaml из wpf. Делаться будет на базе библиотеки SDL и сопутствующих. Я так понимаю, что задачи у нас похожие, вам же тоже надо DOM дерево отрисовать, можем попробовать поработать совместно.
Здравствуйте, Visor2004, Вы писали:
V>Я в следующем феврале начинаю писать рендерер заточенный для отрисовки UI в одном игровом проекте. UI будет описываться в виде xml, наподобие xaml из wpf. Делаться будет на базе библиотеки SDL и сопутствующих. Я так понимаю, что задачи у нас похожие, вам же тоже надо DOM дерево отрисовать, можем попробовать поработать совместно.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Visor2004, Вы писали:
V>>Я в следующем феврале начинаю писать рендерер заточенный для отрисовки UI в одном игровом проекте. UI будет описываться в виде xml, наподобие xaml из wpf. Делаться будет на базе библиотеки SDL и сопутствующих. Я так понимаю, что задачи у нас похожие, вам же тоже надо DOM дерево отрисовать, можем попробовать поработать совместно.
A>Ну от попытки хуже никому не станет.
Задачу и разработку архитектуры я начинаю ставить уже сейчас поэтому мне было бы интересно посмотреть на то, что есть у вас. У вас есть какой-то project place, где хостятся сорцы, где общается комманда? Чтоб я уже сейчас мог учитывать вашу специфику.
Здравствуйте, Visor2004, Вы писали:
A>>Ну от попытки хуже никому не станет. V>Задачу и разработку архитектуры я начинаю ставить уже сейчас поэтому мне было бы интересно посмотреть на то, что есть у вас. У вас есть какой-то project place, где хостятся сорцы, где общается комманда? Чтоб я уже сейчас мог учитывать вашу специфику.
Ну у нас есть пара набросков и несколько разных мнений куда двигаться дальше. Есть репозиторий и проч, но сейчас активной разработки не ведётся. Я честно говоря не уверен что проект в текущем виде будет успешно завершён. Если позволят финансы я изменю формат и он из добровольного станет принудительным. Если не позволят, увы. В любом случае вопрос интеграции очень важный и приоритетный. Вы всегда можете вложить в проект вклад предложив удобный с вашей точки зрения формат интеграции.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Visor2004, Вы писали:
A>>>Ну от попытки хуже никому не станет. V>>Задачу и разработку архитектуры я начинаю ставить уже сейчас поэтому мне было бы интересно посмотреть на то, что есть у вас. У вас есть какой-то project place, где хостятся сорцы, где общается комманда? Чтоб я уже сейчас мог учитывать вашу специфику.
A>Ну у нас есть пара набросков и несколько разных мнений куда двигаться дальше. Есть репозиторий и проч, но сейчас активной разработки не ведётся. Я честно говоря не уверен что проект в текущем виде будет успешно завершён. Если позволят финансы я изменю формат и он из добровольного станет принудительным. Если не позволят, увы. В любом случае вопрос интеграции очень важный и приоритетный. Вы всегда можете вложить в проект вклад предложив удобный с вашей точки зрения формат интеграции.
отписал в личку. Я просто хочу сначала сориентироваться в том, что вообще представляет из себя ваш проект и комманда. Только после этого я смогу понять смогу я вам принести какую-то пользу или нет. Пока у меня есть просто желание заниматься этой тематикой, в феврале будет еще и возможность и необходимость
Здравствуйте, Visor2004, Вы писали:
V>отписал в личку. Я просто хочу сначала сориентироваться в том, что вообще представляет из себя ваш проект и комманда. Только после этого я смогу понять смогу я вам принести какую-то пользу или нет. Пока у меня есть просто желание заниматься этой тематикой, в феврале будет еще и возможность и необходимость
Здравствуйте, adontz, Вы писали:
A>Ну у нас есть пара набросков и несколько разных мнений куда двигаться дальше. Есть репозиторий и проч, но сейчас активной разработки не ведётся. Я честно говоря не уверен что проект в текущем виде будет успешно завершён. Если позволят финансы я изменю формат и он из добровольного станет принудительным. Если не позволят, увы. В любом случае вопрос интеграции очень важный и приоритетный. Вы всегда можете вложить в проект вклад предложив удобный с вашей точки зрения формат интеграции.
Я сейчас занят активно другим проектом, и в ближайшее время времени нет вообще.
Те наброски, что делал я — их — можно смело выкидовать, потому что УГ.
Опять же неясно куда двигаться дальше, даже в более глобальном плане, чем были разногласия.
За последние пару месяцев ещё раз убедился, что css селекторы очень удобны, а вот css-layouting в таком виде как он существует — мне лично не интересен, особенно когда упор делается на UI.
Здравствуйте, fddima, Вы писали:
F> Опять же неясно куда двигаться дальше, даже в более глобальном плане, чем были разногласия. F> За последние пару месяцев ещё раз убедился, что css селекторы очень удобны, а вот css-layouting в таком виде как он существует — мне лично не интересен, особенно когда упор делается на UI.
Ну это как бы не новость. Потому появился XUL, потому Андрей в HTMLayout добавил flow/flex. Делать интерфейс толькон а стандартном CSS занятия мазохистическое. Надо будет расширять.
Вопросы:
1. хостинг проекта. codeplex или какой другой?
2. по поводу HTML parser, может использовать уже готовые описания, например XML Schema для XHTML с W3C сайта. Знаю что это не покроет все, но часть работы может сделать.
Здравствуйте, sergey_shandar, Вы писали:
_>1. хостинг проекта. codeplex или какой другой?
Свой Trac+Mercurial
_>2. по поводу HTML parser, может использовать уже готовые описания, например XML Schema для XHTML с W3C сайта. Знаю что это не покроет все, но часть работы может сделать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, sergey_shandar, Вы писали:
_>>1. хостинг проекта. codeplex или какой другой?
A>Свой Trac+Mercurial
_>>2. по поводу HTML parser, может использовать уже готовые описания, например XML Schema для XHTML с W3C сайта. Знаю что это не покроет все, но часть работы может сделать.
A>Угу.
Тогда некоторые проекты, не считая xsd.exe: LINQ to XSD — MS забросил разработку, я поддерживал его для себя; Xsd2Code — не знаю, не пользовался, интегрируется с VS, у меня Express; CityLizard Framework — пока только из C# в XML, чтение из XML в разработке, многие фичи еще не реализованны (например строготипизированные простые типы simpleType);
Под какой лицензией собираетесь делать? Надеюсь не GPL?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, sergey_shandar, Вы писали:
_>>Под какой лицензией собираетесь делать? Надеюсь не GPL?
A>Лично я за BSD.
Предлагаю тогда Apache 2.0, так как детали проработанны, даже MS выпускает под ней.
Здравствуйте, sergey_shandar, Вы писали:
_>2. по поводу HTML parser, может использовать уже готовые описания, например XML Schema для XHTML с W3C сайта. Знаю что это не покроет все, но часть работы может сделать.
Обычного XML достаточно. Схема там вообще не нужна. Всё что не вписывается в схему едет в аттрибуты, точно так же как это сделано в html5 с data-*.
Обычный HTML — опять же неясно зачем там схема. Набросок парсера есть, очень неэффективного и не поддерживающего несколько состояний, — на мой взгляд это всё лишнее, нужно смотреть исключительно на xhtml/xml.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, sergey_shandar, Вы писали:
_>>2. по поводу HTML parser, может использовать уже готовые описания, например XML Schema для XHTML с W3C сайта. Знаю что это не покроет все, но часть работы может сделать. F> Обычного XML достаточно. Схема там вообще не нужна. Всё что не вписывается в схему едет в аттрибуты, точно так же как это сделано в html5 с data-*. F> Обычный HTML — опять же неясно зачем там схема. Набросок парсера есть, очень неэффективного и не поддерживающего несколько состояний, — на мой взгляд это всё лишнее, нужно смотреть исключительно на xhtml/xml.
Если обычный HTML не нужен, тогда XML Schems приобретает больше смысла. Как минимум — частичная валидация.
Здравствуйте, sergey_shandar, Вы писали:
_>Если обычный HTML не нужен, тогда XML Schems приобретает больше смысла. Как минимум — частичная валидация.
Дело в том что и XHTML и HTML должен быть представлен в DOM. Фактически HTML превращается в XHTML (ну почти), поэтому заострять особо внимание на HTML не вижу особого смысла, на первых порах.
Насчёт валидации — ради бога, никто ж её не отбирает. Я больше к тому что для лайаутинга и рендеринга валидация и схемы бесполезны.
Здравствуйте, adontz, Вы писали:
_>>Предлагаю тогда Apache 2.0, так как детали проработанны, даже MS выпускает под ней. A>Но это же не рифмуется с LSD!
А MIT License не нравится?
Здравствуйте, fddima, Вы писали:
_>>>Предлагаю тогда Apache 2.0, так как детали проработанны, даже MS выпускает под ней. A>>Но это же не рифмуется с LSD! F> А MIT License не нравится?
