Наконец-то!
Только сегодня о баге сообщил в трекер и Филу Хааку написал. Жаль уже не исправят (((
Еще о 2 багах в Razor'е сообщал раньше — один исправили, другой нет.
Я относительно давно знаком со всемы черновиками организации компоновки (grid, flex, layout).
Предудущая инкарнация grid (которая CSS Grid Positioning) как-то немного уступала другим, особенно flex.
Но новая версия (CSS Grid Alignment) смотрится явно интереснее. Все очень предельно просто и понятно. И данный подход решает 99% задач. Ближайший конкурент flex не решает, к примеру, независимость содержимого от представления (нельзя свободно тасовать блоки).
Да, принимает object, но смысл кода в статической типизации (которая генерируется динамически, конечно).
В реальной жизни я использую именно деревья выражений — самый эффективный и правильный способ, на мой взгляд.
Я бы еще при компиляции деревьев выражений убрал приведение типа. Пусть был бы тип делегата Func<StaticObject, T>.
Без приведения с проверкой будет работать быстрее.
По-моему очень интересная и перспективная идея. Если все это будет работать быстро легко и непринужденно, то такое представление кода весьма удобно. Жду такого плагина для студии.
Интересно с каких пор появился оператор methodof?
Эрик Липерт писал, что такого оператора у нас не будет даже в C# 4 — слишком дорого проектировать, тестировать, сопровождать (((
Потрясающе. Стёп, ты хоть сдай этот банк, чтобы знали люди. Я в одном банке тоже с этим bs-клиентом работал, проблем с паролем не было — сразу свой ставил.
Радиоволны — это электромагнитные волны. И разные частоты их могут быть ох как опасными. Если имеется в виду частоты в пределах радиоволн (от нескольких герц до терагерц), то вроде как особо не опасны. А вот все, что выше видимого спектра — очень даже опасны. Тот же самый рентген — им не рекомендуется злоупотреблять.
Видимо вы опять не про то. Я не пишу про то какое решение лучше или хуже для XSLT. Я пишу о том как XHTML представление сериализовывать по HTML-правилам.
Заметьте, это ваши слова: «при помощи лишнего XSLT преобразования». Зачем нужно делать преобразование вообще? Просто есть другие правила форматирования — это не какая-то другая структура. Я не спорю, что можно сделать это на XSLT, но это просто глупо.
А ваше утверждение про мои знания XSLT и процессоров безосновательны. Я здесь не обсуждаю вопросы самого XSLT. Здесь решение задачи вышестоящего уровня.
Я не буду сомневаться в ваших знаниях XSLT, потому как видно, что это единственное слово, которое вы поняли, и не можете понять что статья не он XSLT.
То, что можно наложить еще одно преобразование — сомнений нет, но зачем это делать, если можно просто заменить сериализатор.
Вот взять опять же html5, документ которого описывается некой объектной моделью, которая укладывается в xml. Согласно спецификации она может быть сериализована либо в xhtml (по правилам xml) либо в html (по правилам, которые я привел в статье). Следовательно на входе должна быть объектная модель xml (пусть это бедет XmlDocument, XDocument, XPathNavigator или результат трансформаций) а на выходе текстовое представление в одном из форматов. И задача получить правильное представление ни какого-то дополнительного преобразования, а сериализатора.
А то, что вы предлагаете сделать, это дополнительная ненужная работа — это не кошерно =)
Да, к сожалению, XQuery еще в 2-м фреймворке обещали но потом убрали… жаль.
Но, я бы не стал .Net xslt-процессор так называть — нужно провести реальные замеры производительности чтобы как-то сравнивать.
Какой процессор лучше — это предмет для обсуждения, который данной статьей не поднимался, поэтому и здесь я бы не хотел это обсуждать. У меня есть свое мнение на счет Saxon, которое я также здесь не хочу говорить.
Суть в том, что здесь представлено решение конкретной задачи — использование XmlWriter для форматирования в соответствии с правилами HTML. Что его можно использовать для XSL-трансформаций — это вопрос другой.
Кстати, и все-таки, разве в Saxon можно использовать один и тот же шаблон для генерации XHTML и HTML, без использования хаков в XSLT?
Насколько понял из этого объявления сущности, его разбором будет заниматься XML-парсер на входе в XSLT, что совсем не то, о чем я писал. Здесь имеется в виду запись выходного потока XML по правилам HTML.
Неправильно.
script не может содержать ссылок на сущности. Это raw-text элемент.
Правильный HTML-парсер должен не распознавать ссылки на сущности.
Т.е. в данном случае, это будет трактоваться не как текст «google-analytics-config-compiled.js», а как текст "&google-analytics-config;".
Возможно, вы имели в виду:
<script type="text/javascript" src="&google-analytics-config;"></script>
если так, то — да, так можно. Но это атрибут.
Только сегодня о баге сообщил в трекер и Филу Хааку написал. Жаль уже не исправят (((
Еще о 2 багах в Razor'е сообщал раньше — один исправили, другой нет.
Предудущая инкарнация grid (которая CSS Grid Positioning) как-то немного уступала другим, особенно flex.
Но новая версия (CSS Grid Alignment) смотрится явно интереснее. Все очень предельно просто и понятно. И данный подход решает 99% задач. Ближайший конкурент flex не решает, к примеру, независимость содержимого от представления (нельзя свободно тасовать блоки).
В реальной жизни я использую именно деревья выражений — самый эффективный и правильный способ, на мой взгляд.
Без приведения с проверкой будет работать быстрее.
Эрик Липерт писал, что такого оператора у нас не будет даже в C# 4 — слишком дорого проектировать, тестировать, сопровождать (((
Заметьте, это ваши слова: «при помощи лишнего XSLT преобразования». Зачем нужно делать преобразование вообще? Просто есть другие правила форматирования — это не какая-то другая структура. Я не спорю, что можно сделать это на XSLT, но это просто глупо.
А ваше утверждение про мои знания XSLT и процессоров безосновательны. Я здесь не обсуждаю вопросы самого XSLT. Здесь решение задачи вышестоящего уровня.
Я не буду сомневаться в ваших знаниях XSLT, потому как видно, что это единственное слово, которое вы поняли, и не можете понять что статья не он XSLT.
Вот взять опять же html5, документ которого описывается некой объектной моделью, которая укладывается в xml. Согласно спецификации она может быть сериализована либо в xhtml (по правилам xml) либо в html (по правилам, которые я привел в статье). Следовательно на входе должна быть объектная модель xml (пусть это бедет XmlDocument, XDocument, XPathNavigator или результат трансформаций) а на выходе текстовое представление в одном из форматов. И задача получить правильное представление ни какого-то дополнительного преобразования, а сериализатора.
А то, что вы предлагаете сделать, это дополнительная ненужная работа — это не кошерно =)
Без обид — мы просто, видимо, про разное говорим.
Но, я бы не стал .Net xslt-процессор так называть — нужно провести реальные замеры производительности чтобы как-то сравнивать.
Суть в том, что здесь представлено решение конкретной задачи — использование XmlWriter для форматирования в соответствии с правилами HTML. Что его можно использовать для XSL-трансформаций — это вопрос другой.
Кстати, и все-таки, разве в Saxon можно использовать один и тот же шаблон для генерации XHTML и HTML, без использования хаков в XSLT?
script не может содержать ссылок на сущности. Это raw-text элемент.
Правильный HTML-парсер должен не распознавать ссылки на сущности.
Т.е. в данном случае, это будет трактоваться не как текст «google-analytics-config-compiled.js», а как текст "&google-analytics-config;".
Возможно, вы имели в виду:
<script type="text/javascript" src="&google-analytics-config;"></script>
если так, то — да, так можно. Но это атрибут.