«XOR's Post»

SDF #3. Компоненты в LSD

Andrew Mayorov — Thu, 15 Oct 2009 10:18:00 GMT

Глава третья истории про SDF, в которой мы продолжаем смотреть на обработчик LiveDocument. Что-то делает его «живым», нам надо в этом разобраться. Появляются компоненты IDocumentSource и INodeExtender с примерами.

Чтобы документы в Live Server Documents стали «живыми» надо использовать компоненты, модифицирующие документ. Есть два типа компонентов, реализующих следующие интерфейсы:

IDocumentSource – источник документа. Возвращает XML-документ (или элемент, фрагмент документа), который вставляется в документ вместо этого компонента.
INodeExtender – позволяет модифицировать XML-дерево на входе и на выходе из «расширенного» узла.

Здесь необходимо рассказать о том, как же именно происходит обработка документа. Все довольно прямолинейно. Обработчик LiveDocument загружает документ с диска и начинает просматривать его элемент за элементом. Если он находит известную ему директиву, то совершает положенные действия. Все директивы LSD принадлежат вот такому пространству имен: xmlns:lsd="http://www.byte-force.com/schemas/LSD". Так что если написано “lsd:...”, то этот элемент относится не к данным, а к «активному контенту». Пример директивы:

<lsd:document source="sdf.ModuleStart, sdf">
    <lsd:param name="module-name" value="sdf.Articles"/>
</lsd:document>

Директива выполняется так:

Создается компонент типа “sdf.ModuleStart, sdf”. Этот компонент реализует интерфейс IDocumentSource.
Исполняется метод ProcessRequest, которому передается один параметр. Имя и значение параметра, думаю, очевидны.
Метод возвращает элемент (или кусочек XML-дерева), который и вставляется в обрабатываемый документ вместо всей этой директивы.

А вот пример, в котором используется node extender:

<lsd:extension type="PriceTagExtender">
    <lsd:param name="xsl-doc" value="pricetag-brief.xsl"/>
    <lsd:param name="select" value="sdf:objects/sdf:article"/>

    <lsd:document source="sdf.Persist.ObjectMan, sdf">
        <lsd:param name="parent-path" request-param="$current-site"/>
        <lsd:param name="path" request-param="$path-info"/>
        <lsd:param name="mode" value="object"/>
        <lsd:param name="lang" value="{/sdf:page/sdf:context/@lang}"/>
        <lsd:param name="bookmark-by" value="page-num"/>
        <lsd:param name="xsl-doc" value="article-full.xsl"/>
        <lsd:param name="filter">
            <filter name="isPublished">
                <param name="view" value="published"/>
            </filter>
            <filter name="hasLocale">
                <param name="lang" lsd:request-param="$current-lang"/>
            </filter>
        </lsd:param>
    </lsd:document>
</lsd:extension>

Здесь происходит следующее:

Когда обработчик подходит к узлу “lsd:extension”, он создает объект с типом “PriceTagExtender”. Пытливый читатель заметит, что это неправильное имя типа – нет неймспейса и имени сборки. Действительно, LSD понимает не только полные имена типов, но и логические имена компонентов (заданные в web.config).
При входе в элемент “lsd:extension” вызывается метод INodeExtender.PreProcessNode, в который передаются два аргумента: xsl-doc и select.
У данного конкретного экстендера метод PreProcessNode ничего не делает, так что обработка просто идет дальше.
Вызывается компонент “sdf.Persist.ObjectMan, sdf”. Он отрабатывает, возвращая XML-представление объектов, полученных из базы данных. Полученный XML вставляется в документ вместо директивы “lsd:document”.
Обработка подошла к выходу из узла “lsd:extension”, и, соответственно, вызывается метод INodeExtender.PostProcessNode. В этот раз внутри узла, переданного на обработку, находятся объекты, полученные из база данных. Экстендер выбирает элементы по заданному XPath-выражению (sdf:objects/sdf:article) и добавляет к ним цену.
Выполнение метода PostProcessNode закончено и LiveDocument убирает элемент “lsd:extension” из документа. При этом, конечно, все содержимое узла остается.

А вот и интерфейсы компонентов. Они совершенно очевидны:

public interface IDocumentSource 
{
    XmlNode GetDocument( HttpContext context, NameObjectCollection args );
}

public interface INodeExtender 
{
    void PreProcessNode( 
        HttpContext context, XmlNode node, NameObjectCollection args );
    void PostProcessNode( 
        HttpContext context, XmlNode node, NameObjectCollection args );
}

В сегодняшней фотосессии – модуль управления структурой сайта (папками, проще говоря).

SDF #2. Серверные XSLT-трансформации

Andrew Mayorov — Wed, 14 Oct 2009 09:23:00 GMT

Глава вторая истории про SDF, в которой мы кладем на операционный стол хэндлер для файлов с расширением “.sdf” и начинаем его внимательно рассматривать. Для начала разбираемся, для чего он нужен.

ASP.NET – отличная платформа для разработки сайтов, но при этом их стандартный способ рендеринга страниц просто ужасен. Я говорю про Web Forms. На мой взгляд, попытка притащить привычный всем дизайнер форм в веб провалилась. Причем формы-то получаются нормальные, а вот страницы в целом – вовсе нет.

Я считаю, что лучший язык для формирования HTML – это XSLT, и, соответственно, исходные данные для этого должны подаваться в виде XML. В принципе, любой современный браузер может загрузить XML-документ и применить XSLT-трансформацию прямо на клиентской стороне, но такой подход используется редко. Во-первых, не все браузеры современны. Во-вторых, не всегда уместно тащить все данные на клиент. Возможно, мы должны обработать большой массив информации и выдать краткий ответ. Делать это на клиенте, конечно, не разумно. Наконец, клиентская трансформация просто не прижилась пока. «Так сейчас не носят».

Нужен механизм, который берет XML-документ, лежащий на сервере, тут же трансформирует его при помощи назначенного документу XSLT-файла, и засылает результат клиенту. В SDF для этого служит подсистема LSD – Live Server Documents. Чтобы использовать ее, надо подключить к сайту специальный HttpHandler. Добавьте следующее в web.config:

<httpHandlers>
    <add verb="*" path="*.sdf" type="lsd.LiveDocument,lsd" />
    ...
</httpHandlers>

Обратите внимание, что мы вешаем хэндлер на файлы с расширением “.sdf”, а значит именно так у нас обычно и называются серверные XML-документы. Тот факт, что Visual Studio 2008 оккупировало это расширение под свои нужды, считаем происками врагов. Мы раньше начали и пока продолжаем. Но вам никто не мешает выбрать любое другое расширение.

Чтобы проверить серверную трансформацию:

Делаете XML-документ “test.sdf” и кладете его на сервер.
Создаете XSLT (“test.xslt”), который преобразует этот документ в HTML.
Добавляете в “test.sdf” директиву:
<?xml-stylesheet language=”text/xsl” href=”test.xsl” ?>
Открываете файл в браузере и убеждаетесь, что это HTML.

Это уже удобно для создания статического сайта – все ваши данные лежат по файлам XML, а все их представления – по файлам XSLT. Получается MVC без одного компонента – без контроллера. Но и он тоже у нас есть.

Для того, чтобы контролировать процесс формирования документа, в LSD есть директивы, позволяющие выполнять код, модифицирующий этот XML-документ перед трансформацией. Собственно, поэтому эта подсистема и называется «Живые Серверные Документы». Но про это мы будем говорить уже не сегодня.

Продолжение »

Сегодняшняя картинка – индексная страница sdf.CPanel (или просто цэпанели):

Да, я знаю, похоже на iPhone. :)

SDF #1. О чем это вообще?

Andrew Mayorov — Tue, 13 Oct 2009 08:30:00 GMT

Время идет, SDF развивается, появляются пользователи уже и за стенами BYTE-force, а хорошей документации все нет и нет. Я решил пока начать писать короткие заметочки про SDF, которые бы так или иначе помогали понять его суть. Пишу в наш публичный блог, чтобы уж сразу все желающие видели. Нам скрывать нечего.

Итак, что такое SDF?

SDF – это фреймворк (или движок) для разработки сайтов и веб-приложений. Выстроен поверх ASP.NET. Включает в себя несколько подсистем:

HttpHandler LiveDocument, который собирает XML-документ из компонентов и прогоняет через XSLT-трансформацию.
Система ограничения доступа ForceField.NET.
sdf.XPath – известный многим ObjectXPathNavigator.
Ядро SDF. Обеспечивает работу с объектами в базе данных.
sdf.CPanel – CMS для управления объектами SDF.
Плюс дополнительные модули.

Рассказывать про все сразу не получится, ибо слои приложения разнообразны и достаточно независимы. Поэтому буду перескакивать с пятого на десятое. Надеюсь, что, в процессе прочтения заметок, у вас будет складываться общая картина.

Да, кстати, я не ответил на вопрос: что означает «SDF»? Открою великую тайну – это аббревиатура «Site Development Framework». Банально, но так уж сложилось исторически.

Зачем это?

Зачем это нужно, если уже есть куча готовых решений? Тому есть несколько причин:

Мы начали делать SDF в 2001 году. Тогда уже была вторая бэта-версия .NET Framework, а вот кучи готовых решений под него еще не было.
Нам не нравятся Web Forms, которые следовало использовать по официальной идеологии MS. Вместо этого хотелось использовать XSLT. Похожее решение есть только на Яве – это Cocoon, и он не настолько популярен, чтобы его портировали под .NET (до сих пор).
SDF – это не только веб-движок, но еще и идеология иерархического хранения объектов. Для этого сделана специальная структура базы данных, с которой мы и работаем. Пока удается с удобством загнать в нее большинство решаемых задач.

Можно продолжать список, но пока хватит.

Продолжение »

Скриншот логиновой страницы

Неладно что-то в HttpApplication

Andrew Mayorov — Fri, 09 Oct 2009 15:07:36 GMT

Угробил кучу времени на такую вот проблему. Цепляю обработчик на событие HttpApplication.PostAuthenticateRequest, а он не срабатывает. Причем раньше все работало, а после, казалось бы, небольшого рефакторинга перестало. После долгих разбирательств оказалось, что когда приложение полностью проинициализировано, его события уже нельзя менять. Я не могу ни подписаться на событие, ни отписаться от события. Все заморожено.

Другими словами, цепляться на события приложения можно только в методе HttpApplication.Init() или в Application_Start() в global.asax.cs. Зачем придуманы такие ограничения, для меня совершенно непонятно.

Корень же проблемы в том, что в ASP.NET есть только одна возможность сделать что-то по старту приложения – метод Application_Start. Ясно, что из своего модуля ты в этот метод не подпихнешься. Если делаешь инициализацию в методе Init() модуля, то в это время еще не готово само приложение. Некоторые методы могут быть недоступны. Например, MapPath. Пригодилось бы событие HttpApplication.AfterInit, но такого нет. Вот я и пытался сделать инициализацию по первому событию BeginRequest. Не получилось.

Возможно, нам поможет preload, но он будет еще только в следующей версии АСП. А пока помним, что подписываться на события можно не всегда.

CEE-SECR 2009

Andrew Mayorov — Mon, 05 Oct 2009 08:13:00 GMT

Нашел свой доклад про XSLT в списке докладов конференции «Разработка ПО 2009» (CEE-SECR). Придется съездить, посмотреть, как там что. :)

Update:

Опубликовали страничку про мой доклад. С моей же физиономией. Какая-то странная фотография, а? :)

Google Chrome Frame

Andrew Mayorov — Wed, 23 Sep 2009 10:00:29 GMT

Google Chrome Frame - интереснейшая вещь. Это примочка к IE (6, 7, 8), которая показывает страницу во внедренном в IE Хроме. В деталях не разбирался. Скорее всего, в страницу внедряется ActiveX с Chrome внутри. Ну может хоть так удастся IE забороть.

Вдогонку к докладу Макса про рефлекшен

Andrew Mayorov — Tue, 22 Sep 2009 09:43:48 GMT

Так как доклад Макса Высоких мне очень понравился, я сходу решил улучшить ObjectXPathNavigator, избавив его от чтения значений свойств через Reflection. Сказано – сделано. Сумел успешно применить оба метода: и через генерацию лямбда-выражений, и через DynamicMethod.

Но вот незадача: потестировав скорость, я не увидел большой разницы. Максимум процентов 7. От запуска к запуску наблюдаются отклонения – примерно %0.5. Так что и тот максимум мог еще под погрешность попасть.

Признаюсь, правда, что тестировал я спустя рукава – просто сделал юнит-тест с 100000 итераций и посмотрел время, которое запускалка тестов показывает. Возможно, она и врет, но вряд ли как Троцкий. Да и трассировка показывает, что все эти вызовы занимают только 0.27 процентов всего времени работы. А генерация делегатов – 0.47 сотых. И это всего за 4 вызова! Кстати, генерация акцессора для поля на порядок дольше, чем для свойства. Так что не ленитесь делать свойства.

Но раз работа сделана, то выбрасывать ее как-то глупо. Решил остановиться на динамических методах, так как у Макса выходило, что это лучшее решение. И тут оказалось, что этот подход не работает в ASP.NET. Генерирует эксепшен: “System.Security.VerificationException: Operation could destabilize the runtime.”. Пришлось вернуться к лямбда-выражениям.

Мораль проста: даже если рефлекшен медленнее прямого вызова в 80 раз, в сложных процессах это вообще не играет роли. Так что не напрягайтесь.

Про пятничный семинар

Andrew Mayorov — Mon, 21 Sep 2009 09:18:48 GMT

Тусовка в пятницу очень понравилась. Особенно доклад Макса Высоких. У него всегда отлично получается, а тут было просто великолепно. Все, кто поленился прийти, кусайте локти. Ну и рассматривайте материалы самостоятельно. Я свой доклад опубликовал к нам и на сайт YaNA (ищите, там где-то есть ссылочка).

Еще мы с самыми активными камрадами здорово посидели после семинара за кружечкой пива. Это вот надо бы в традицию ввести. :)

И вообще, такая вот идея возникла. Проводить регулярно беседы и транслировать их в интернет. Как бы такое ток-шоу локального масштаба. Чтобы можно было слушать беседы, а можно было написать или позвонить по скайпу. Звонящий тоже появляется в эфире, как если бы он тоже пришел. Ясно, что такое должно проходить регулярно, иначе постоянная аудитория не сформируется. И вот как раз регулярность какой-то одной маленькой группе обеспечить сложно. Представьте, каждую пятницу, например, устраивать эфир. Задолбает.

Другое дело, если бы была такая кафуха, где собираются программисты. Не обязательно одни и те же, но всегда есть достаточное количество, чтобы было кого послушать. С разных столиков можно разные дискуссии транслировать, кстати.

В дженериках C# мог бы быть полезен “this type”

Andrew Mayorov — Wed, 16 Sep 2009 06:56:48 GMT

Разбирая наш код, нашел место, которое явно требовало бы некоторой подчистки. Но чтобы почистить, в языке нужна бы еще фича, которую и хочу обсудить. Я поднимал этот вопрос также и на StackOverflow. Был поддержан авторитетным камрадом.

Возьмем два класса, один наследуют от другого. Базовый класс – дженерик, в котором есть метод, который в производном закрытом типе должен возвращать экземпляр этого самаого закрытого типа.

Например, так (обратите внимание на ??? в тексте):

public class Adapter<T>
{
 public virtual ??? DoSomething()
 {
  ...
 }
}

public class AdaptedString : Adapter<String>
{
 public override AdaptedString DoSomething()
 {
  ...
 }
}

Так сделать нельзя, так как в нет способа сослаться на тип, получающийся при “закрытии” дженерика. Нет такого ключевого слова, которым можно заменить “???”, чтобы указать, что этот метод будет возвращать экземпляр производного закрытого класса.

Вместо этого остается только обходное решение. Надо явным образом передавать тип в базовый класс. Получается явно избыточно:

public class Adapter<TThis,T>
{
 public virtual TThis DoSomething()
 {
  ...
 }
}

public class AdaptedString : Adapter<AdaptedString,String>
{
 public override AdaptedString DoSomething()
 {
  ...
 }
}

А если в базовом классе нужно обращаться к методам экземпляра типа TThis, то приходится добавлять констрейнт. И получается совсем страшно:

public class Adapter<TThis,T>
 where TThis : Adapter<TThis, T>
{
 protected int _field; 

 ...

 public bool Compare( TThis obj )
 {
  return _field == obj._field;
 }
}

public class AdaptedString : Adapter<AdaptedString,String>
{
 ...
}

В принципе, это работает. Но выглядит очень непонятно. Каждый раз, когда смотришь на этот код, путаешься, и нужно какой-то время, чтобы разобраться кто есть кто.

Кажется было бы гораздо удобнее, если бы можно было как-то указать, что “TThis” должен быть этим типом. Может быть использовать какое-нибудь ключевое слово. Типа “thistype”, хотя это тоже выглядит страшно. Может быть констрейнт ввести: where TThis: this type.

А то ведь получается, что этот окружной путь позволяет запросто накосячить:

class TypeA : Adapter<TypeA, string>



class TypeB : Adapter<TypeA, string> // Bug!

PostSharp. Реализация INotifyPropertyChanged

Andrew Mayorov — Tue, 15 Sep 2009 07:59:00 GMT

PostSharp – инструмент для аспектно-ориентированного программирования (AOP). Сделан здорово; руки постоянно чешутся заюзать его для чего-нибудь. Но найти хорошее применение для аспектов не так и просто. Возможно, просто мозг еще в правильном направлении не повернут, не знаю.

В блоге проекта появился пример действительно отличного применения – реализация интерфейса INotifyPropertyChanged. Его ручная реализация настолько скучна, что просто пугает. А тут достаточно написать аспект и использовать его вот так:

[NotifyPropertyChanged]
public class TestBaseClass
{
    public string PropertyA { get; set; }
}

Причем сам аспект реально прост и логичен.

XsltView для MVC Framework

Andrew Mayorov — Mon, 14 Sep 2009 20:26:27 GMT

Не прошло и года с тех пор, как я ругал реализацию XsltViewEngine в MvcContrib, как я взял, и переделал эту штуку с использованием ObjectXPathNavigator. Выбросил, пожалуй, три четверти кода, осталось всего четыре ма-аленьких класса. И все работает. :) Надо только еще добавить специальную политику для класса ViewDataDictionary. Чтобы xpath-выражения для работы со входными данными попроще были.

Должен сказать, что с объектом Html в этих шаблонах работать нельзя. Ну понятно, это же не веб-формы со внедренным кодом на C# – это XSLT. Думается, что это можно решить правильно сделанным объектом расширения с кастомными функциями. Надо только хорошо это обдумать. Все-то методы из хелперов тащить туда точно не надо.

YaNA – в следующую пятницу

Andrew Mayorov — Fri, 11 Sep 2009 08:33:00 GMT

В следующую пятницу, 18 сентября 2009, состоится очередной семинар Yaroslavl .NET UG (YaNA). С точным местом пока не определились. Либо нам дадут обычную аудиторию в первом корпусе ЯрГУ, либо мы проведем все у нас в BYTE-force. В тесноте, но не в обиде. Следите за эфиром.

Update: Семинар пройдет в обычном месте. Чуть раньше чем всегда, не в 7 вечера, а в 18:30. Все-таки пятница.

Светящийся стакан

Andrew Mayorov — Mon, 07 Sep 2009 16:35:00 GMT

Студия Артемия Лебедева продает светящийся стакан “Люминарус”. Берешь его в руку — зажигается подсветка.

Вещь интересная, но все же не то, что нужно. Какая-то, знаете, индивидуалистская. Надо чтобы это работало так:

Разливаем по рюмкам.
«Тостующий» берет рюмку и говорит тост. Рюмка загорается. Причем яркость может зависеть от длины тоста.
Начинает чокаться и передает свечение другим.
Выпили — все плавно погасло.

Получаем девайс для дружной компании. Это же завсегда лучше, чем пить в одиночку. :)

Если помните, такую штуку мы обсуждали несколько лет назад. Может кто и сделает?

(Кросспост с хабра. Интересно, что там он очень неоднозначную оценку получил. Куча людей против и только чуть-чуть больше - за. Непонятная реакция. Я бы понял, если бы было все равно.)

Can we use CSS-sprite for custom fonts?

Andrew Mayorov — Tue, 01 Sep 2009 17:32:00 GMT

I wonder if it is possible to use CSS-sprites to output header text with custom fonts?

Looks like it’s not hard to implement:

Prepare CSS-sprite with font – output all letters in single image and make CSS file, which contains separate class for each letter. Class defines letter dimensions and background position, as usual.
Mark HTML element to tranform with certain class.
In onLoad event select all elements to transform and substitute each letter with span with respective class.
Original letter goes into the span. It should be almost transparent so it is not visible, but can be selected. It will be also good if size of the original letter will be close to the size of letter in custom font. This will make selection more natural.

Finally, we can make code on the server, that makes such sprite out of font (TrueType for example). This code could be run even at compile time, so it won’t impact run time experience at all.

This method definitely have problems with kerning so for some fonts output won’t be perfect. But we can try to define kerning pairs in JavaScript file and adjust letter positions with margins. If there are not that many pairs in the particular font, it can work out.

It is more a theoretical thing. Will it work? Will it lood good? Will it be faster than canvas- or flash-based solutions? Finally, maybe such approach is not new already?

Update:

As I expected, such solution already exists - fontjazz.com. It doesn't allow for text copying, but it should be quite easy to add this. Thanks nuxdie for the link.

(Crossposted with translation from Habrahabr.)

Ext.ux.TinyMCE v0.7 b1

Andrew Mayorov — Mon, 03 Aug 2009 10:32:17 GMT

I’ve updated Ext.ux.TinyMCE to version 0.7 beta 1. It now surely works with Ext 3.0 and latest TinyMCE. Fixed some issues with resizing, focusing and so on. Applied changes, proposed by community. For now code is only available from this forum post.

Please report any problems and bugs to the forum.