Комментарии 20
Как насчет?
Крута, ждал такой статьи.
Имхо, не самое гибкое решение для подобной задачи. При каждом изменении шаблона потребуется пересобирать, да еще и нужен доступ к файловой системе для создания сборок.
Я как-то не вижу плюсов, хотя бы сравнение скорости привели, что ли.
Я как-то не вижу плюсов, хотя бы сравнение скорости привели, что ли.
Хмм. ну так можно собирать динамически, после каждого измнения шаблона.
Для файловой системы можно использовать временные папки, через Path.GetTempPath()
Для файловой системы можно использовать временные папки, через Path.GetTempPath()
Это понятно, что можно. Вопрос не в этом, вопрос в том, что на том же NVelocity,
я пишу:
и получаю на выходе тот же результат:
Поэтому мне интересно — нафига мне писать в 10 раз больше, заморачиваться перекомпиляцией и временными папками, какие от этого плюсы?
я пишу:
var employee = new Employee(){Name = "Vasya", LastName = "Pupkin"};
VelocityContext context = new VelocityContext();
context.Put("employee", employee);
string template = @"Greetings, $employee.Name $employee.LastName!";
using(System.IO.StringWriter writer = new System.IO.StringWriter())
{
Velocity.MergeTemplate(template, context, writer);
}
и получаю на выходе тот же результат:
Greetings, Vasya Pupkin!
Поэтому мне интересно — нафига мне писать в 10 раз больше, заморачиваться перекомпиляцией и временными папками, какие от этого плюсы?
Возможно есть плюс за счет прекомпилированной сборки, которая представляет собой просто набор команд Response.Write(..).
Я незнаком с NVelocity, так что думаю вы правы и было бы неплохо провести тесты.
Я незнаком с NVelocity, так что думаю вы правы и было бы неплохо провести тесты.
Ну, в данном конкретном случае, возможно, что выгоды и не будет. Но я думаю, что всегда полезно знать о нескольких возможных путях решения задачи, чтобы при необходимости выбрать лучший.
Советую блог Рика Страля почитать
Мне его статья понравилась больше, чем Эндрю.
www.west-wind.com/weblog/posts/864461.aspx
www.west-wind.com/weblog/posts/881577.aspx
Мне его статья понравилась больше, чем Эндрю.
www.west-wind.com/weblog/posts/864461.aspx
www.west-wind.com/weblog/posts/881577.aspx
А вот у меня вопрос к знатокам. Я с MVC пока особо не знаком, так что, возможно, спрашиваю какую-нибудь глупость, но зачем было писать новый движок, когда есть XSLT? И, если подобное имеет смысл, то, может, есть уже где-нибудь результаты сравнения производительности/потребления памяти Razer vs XSLT?
Впрос тока в удобстве. У меня XSLT не ассоциируется с удобством.
быстрее должен быть однозначно. но на сколько, было бы интересно глянуть.
ASP.NET MVC позволяет использовать разные движки представлений. Можно даже свой написать в принципе. Razor — это Microsoft'овская более лаконичная альтернатива своему же движку WebForms (ну или как он там правильно)
Тож в копилочку
razorengine.codeplex.com/
var template = "Hello @Model.Name! Welcome to Razor!";
var result = Razor.Parse(template, new { Name = "World" });
razorengine.codeplex.com/
Ссылка на перевод краткого справочника по синтаксису Razor уже битая. Перевод также, как и оригинальная статья, был обновлен и теперь находиться по адресу — taritsyn.wordpress.com/2011/01/08/kratkij-spravochnik-po-sintaksisu-razor.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Razor за пределами ASP.NET