Комментарии 19
не видно преимуществ, чтобы использовать этот метод на практике (преимуществ, которые бы перевесили необходимость загрязнять инфраструктурными элементами модель, использование многословного xslt, за которым теряется сама вьюшка). Скорость трансформации тоже под вопросом.
Возможно его можно использовать для отдельных action-ов (напр. для генернации отчетов по шаблонам), но не для view. Да и в качестве движка шаблонов я не вижу преимуществ xslt по сравнению напр. с NVelocity, на котором шаблоны выглядят гораздо читабельнее и понятней.
Возможно его можно использовать для отдельных action-ов (напр. для генернации отчетов по шаблонам), но не для view. Да и в качестве движка шаблонов я не вижу преимуществ xslt по сравнению напр. с NVelocity, на котором шаблоны выглядят гораздо читабельнее и понятней.
Некорректно сравнивать XSLT ни с NVelocity, ни с любым другим «шаблонизатором». Дело в том XSLT — функциональный язык, и при правильном использовании он гораздо мощнее императивных конкурентов. Аналогично F#, например, гораздо удобнее и лаконичнее C# для решения определенного класса задач.
НЛО прилетело и опубликовало эту надпись здесь
Мне этот шаблонизатор нравится за счёт того, что он не привязан к конкретной платформе, в отличие от многих других. Его с тем же успехом можно использовать при web-разработке например на php или на другом языке.
Опять же, многие IDE поддерживают автодополнение для XSLT, чем его многословность компенсируется.
Всецело поддерживаю использование XSLT, но вот только подход со стандартной сериализацией не очень хорош. Поэтому вдогонку заметке предлагаю дополнительное чтение:
1. blogs.byte-force.com/xor/archive/2009/02/26/2764.aspx — критика XsltViewEngine из MVCContrib.
2. blogs.byte-force.com/media/p/14328.aspx — слайды с доклада про более правильный подход.
1. blogs.byte-force.com/xor/archive/2009/02/26/2764.aspx — критика XsltViewEngine из MVCContrib.
2. blogs.byte-force.com/media/p/14328.aspx — слайды с доклада про более правильный подход.
Интересный подход.
Маленькое замечание: по-моему, в XmlResult надо передавать объект модели, а не строку, и строку формировать уже внутри--тогда код для сериализации можно будет убрать из контроллера. Это улучшит разбиение по слоям, система будет соответствовать Single Responsibility Principle, и views станут взаимозаменяемыми (можно будет легко заменить XmlResult на любой другой).
Маленькое замечание: по-моему, в XmlResult надо передавать объект модели, а не строку, и строку формировать уже внутри--тогда код для сериализации можно будет убрать из контроллера. Это улучшит разбиение по слоям, система будет соответствовать Single Responsibility Principle, и views станут взаимозаменяемыми (можно будет легко заменить XmlResult на любой другой).
НЛО прилетело и опубликовало эту надпись здесь
Да, в этом варианте всегда загружается главный шаблон, который в свою очередь инктудит остальные. Снижения производительности от этого я не заметил, так что большого минуса я в этом не вижу. Кроме того, в этом случае шаблоны почти не связаны с остальной частью проекта. По сути они связаны только со структурой входного XML'я.
По поводу громоздкости XSLT: можно посмотреть на пример, где получается действительно излишне громоздкий код?
По поводу громоздкости XSLT: можно посмотреть на пример, где получается действительно излишне громоздкий код?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование XSLT-шаблонизатора в ASP.NET MVC