Comments 19
не видно преимуществ, чтобы использовать этот метод на практике (преимуществ, которые бы перевесили необходимость загрязнять инфраструктурными элементами модель, использование многословного xslt, за которым теряется сама вьюшка). Скорость трансформации тоже под вопросом.
Возможно его можно использовать для отдельных action-ов (напр. для генернации отчетов по шаблонам), но не для view. Да и в качестве движка шаблонов я не вижу преимуществ xslt по сравнению напр. с NVelocity, на котором шаблоны выглядят гораздо читабельнее и понятней.
Возможно его можно использовать для отдельных action-ов (напр. для генернации отчетов по шаблонам), но не для view. Да и в качестве движка шаблонов я не вижу преимуществ xslt по сравнению напр. с NVelocity, на котором шаблоны выглядят гораздо читабельнее и понятней.
Некорректно сравнивать XSLT ни с NVelocity, ни с любым другим «шаблонизатором». Дело в том XSLT — функциональный язык, и при правильном использовании он гораздо мощнее императивных конкурентов. Аналогично F#, например, гораздо удобнее и лаконичнее C# для решения определенного класса задач.
XSLT дает гораздо больше возможностей. Он избыточен для простых шаблонов и незаменим для сложных. Его плюс — невероятная гибкость. Я сам не верстальщик, но интересовался этим вопросом у наших верстальщиков. У меня тоже были сомнения хорошая ли эта технология. Лично мне, как не верстальщику, очень трудно разбираться в XSL шаблонах, однако верстальщики хором заявили, что ни за что не променяют его на другой шаблонизатор.
Мне этот шаблонизатор нравится за счёт того, что он не привязан к конкретной платформе, в отличие от многих других. Его с тем же успехом можно использовать при 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 на любой другой).
UFO just landed and posted this here
Да, в этом варианте всегда загружается главный шаблон, который в свою очередь инктудит остальные. Снижения производительности от этого я не заметил, так что большого минуса я в этом не вижу. Кроме того, в этом случае шаблоны почти не связаны с остальной частью проекта. По сути они связаны только со структурой входного XML'я.
По поводу громоздкости XSLT: можно посмотреть на пример, где получается действительно излишне громоздкий код?
По поводу громоздкости XSLT: можно посмотреть на пример, где получается действительно излишне громоздкий код?
Sign up to leave a comment.
Использование XSLT-шаблонизатора в ASP.NET MVC