Как стать автором
Обновить

Комментарии 37

Только мне одной кажется, или Microsoft опять изобрела телефон, тьфу, PHP?
Конечно, давайте посмотрим на велосипед от PHP
<?php echo «lalal»; ?>

<? foreach($m as $k):
echo $k;
endforeach;
?>
а если еще начать использовать фигурные скобки с разрывом кода для html, то тут труба полнейшая

Если уже сравнивать, то лучше с Ruby.
<?=$lalala?>
<?php foreach($m as $k):?>
<?=$k?>
<?php endforeach?>
Это вы называете изящно? Я уже давно работаю с php и прекрасно знаю все отрицательные стороны синтаксиса. <?= не спасает, на сложных конструкциях начинаются пляски. Далее, я(как и многие другие проекты, включая Magento) всегда придерживаюсь Zend Coding Standards. Где четко указано
PHP code must always be delimited by the full-form, standard PHP tags:
Нет не одной :)
Неплохо… А как с производительностью?
Я процитирую Скотта
«Razor is fully compiled — so the performance should be great.»
«Процесс программирования станет быстрым и веселым» :-)
microsoft велик )
Простые языковые конструкции — это понятно. А как насчет поддержки более сложных, например, лямбда-выражений?
Вы получите поддержку всех возможностей языка, включая лямба-выражения.
Ну вот, это уже намного изящнее стандартного движка. Жаль что нет еще самой беты, получился конь впереди повозки. )
ScottGu всегда так делает. Оно кстати и не плохо. Они фидбек еще до бета релиза собирают.
Интересно, чем тогда им упомянутый Haml не понравился. По их критерию, там ещё почти вдвое меньше нажатий клавиатуры, так как закрывающих тегов нет.
наверное, NHaml им бы не удалось расширить так, как они захотят. например добавить декларативные хелперы всякие и прочие плюшки. А тут свое — крути-верти как хочешь.
Плюс, Скотт пообещал постараться предоставить исходный код всего движка, это будет превосходно
О, потехоньку осваиваю asp.net, и буквально первое что мя в стандартном view-engine'е смутило- это не понятки как писать код, а-ля ProductListing.
В результате обычный C#'овский метод-хелпер сделал, но извините — в ручную склеивать строки разметки и серверного кода — это маразм…
Делаете PartialView моделью которого является список продуктов. Далее вызываете Html.RenderPartial.
Попробую. Сенкс.
Грубая аналогия, даже для того, чтобы вывести переменную они использую лишние фигурные скобки
echo <span>Hello, {$_POST['name']}</span>

Ну, тут тоже как бы с собачки нужно начинать те части, где вставляется значение переменной :). Я, на самом деле, скорее имел ввиду реализацию — что оно просто реализует поддержку XML. Но, посмотрев на примеры, беру свои слова обратно — здесь, похоже, они действительно сделали настоящий парсер C# после собачки :)
Очень интересно… когда всё это можно ожидать, чтобы «пощупать»?

Сразу маленький вопросик про конфликты с «собакой»
допустим надо сделать такое:

Адрес для контактов: info@Model.ActiveDomainForEmail


как такое отработает? т.е. Model.ActiveDomainForEmail — допустим содержит "@mydomain.ru" и надо чтобы в результирующем html было info@mydomain.ru
не подумает ли парсер, что info@Model.ActiveDomainForEmail это валидный email?
Предположительно, пощупаем мы в ближайшее 2 недели.
Нет парсер все правильно найдет, у вас же есть свойства в модели. Парсер не смотрит внутрь значений, он смотрит является ли, то что вы написали справа от @ C#-кодом
Хорошо, допустим написано такое:

Адрес для контактов: info@somefield.ru

при этом somefield — это доступная переменная, ссылка на объект, а в нем строковое поле ru, содержащее строку "@mydomain.ru"
понятно что пример синтетический, просто хочется понять, не будет ли вдруг такая «умная» краткая запись причиной путаницы
Нет, потому что парсер не проверяет валидность доменных имен, он ищет c# код. Я не могу ручаться на 100%, но иначе быть не может, там парни не дураки писали :)
а тогда одна опечатка и info@Model.ActiveDomainForEmail так и впечатается в форму
и не понятно как с ошибками компиляции, ведь пишет что не надо закрывать выражение потому что парсер поймет где оно кончилось… значит опять же буквой ошибся и досвидание
Я думаю info@Model.* будет выкидывать ошибку при и пользовании ошибочного свойства.
парсер понимает большинство ситуаций, но когда вы не доверяете ему, то можете экранировать @ с помощью двойного написания @@, в статье про это кстати написано
Я про обратную ситуацию. Экранировать — это понятно, когда я хочу получить собаку в результирующий html, а я пишу про то, что мне кажется не будет понято парсером как C# код, хотя это он и есть
Есть ощущение, что этот синтаксис эквивалентен aspx с точностью до подстановочных знаков: т.е. автоматизированным способом razor-синтаксис конвертится в классическую aspx-разметку, а дальше по накатанной.

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

Скорее всего буду использовать ее в своем проекте. Как раз заканчиваю писать модель и юнит-тесты, а к веб-части пока не приступал.

Кстати, кто-нибудь знает известные known issues? Ограничения и т.д.?
Неплохо, код шаблонов и правда почище в целом будет.
Ну, так оно и есть, в принципе.
Я так понимаю товарищи взяли и реализовали то что уже давно было в PHP, Java и прочих ориентированных на веб языках — MVC то появился недавно в .NET а тут банальный JSTL выдают за чудо технологию
при использовании @Html.BeginForm() в разметку выдается лишний текст «System.Web.Mvc.Html.MvcForm»

никто не сталкивался?
@using (Html.BeginForm(«метод», «контроллер»))
{
здесь форма
}
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории