Комментарии 24
Используйте тэг habracut, пожалуйста.
В общем и целом согласен, хотя 4 и 5 пункты это только ваше имхо, основанное на личном опыте (у меня он диаметрально противоположный). А в общем и целом все укладывается в одну фразу - любая технология/разработка хороша к месту.
Некоторые места сильно улыбнули.
Автор вообще не в теме.
Автор вообще не в теме.
Серебряной пули не бывает, и XSLT не является исключением; тут автор прав. А вот пятый пункт ошибочен code reuse в XSLT наблюдается, и при умелом применении очень даже работает на практике.
XSLT это способ несложного преобразования данных. XPath и XSLT - не синонимы. Я как-то переписал систему с XSLT на lxml - скорость возросла на порядок при том что все XPath-запросы остались на месте. А в общем-то правда в том, что всему своё время и место. Например у нас есть код, который порождает XML с данными и они могут преобразовываться в HTML для нормальной версии сайта и в WML для мобильной. Для такой деятельности XSLT подходит идеально. Но этим способом готовится только фрагмент, который вклеивается в нужное место сайта. А сам сайт делается с использованием совсем других шаблонов (ну это наша специфика, не всем нужно отрабатывать сотни QPS).
А не кажется ли вам, что XML и XSLT предназначены не совсем для того, для чего вы их применяете ? По мне так по меньшей мере странно создавать сайт со сложным динамическим контентом (с AJAX, да даже просто форум) и сложной бизнес-логикой используя набор технологий XML. ИМХО эти технологии в такой задаче не к месту.
Обработать данные - да, вывести статичную страничку на основе данных - да, в конце концов одна из основных целей XML-XSLT-XPath - работать с структурированными данными, преобразовывать их в функциональном стиле. А генерацию динамичаских сложных страниц не стоит валить в эту кучу.
Неудивительно, что выбрав хрустальную вазу для забивания гвоздей через некоторое время убеждаешься, что молоток-то удобней. В Вашей статье основная часть описывает больше то, как забивали гвозди хрустальной вазой, и да, действительно неудобно, и куча недостатков. А вот в конце уже правильная мысль - технология должна быть к месту, но лучше задумываться об этом ДО начала создания проекта, "будет ли к месту технология А или Б", а не - "Возьмем технологию А" а через 6 месяцев - "технология А - г.но потому как не помогла нам в проекте".
А можно задать встречный вопрос - а что вы хотели сказать этой заметкой ? Что серебрянных пуль не бывает ? Я думаю 90% процентов посетителей Хабра это знают, читали Брукса. А дальше-то что ? "Не верьте рекламе" - ну тоже в общем-то Америку не открыли. Если честно - от текста у меня сложилось ощущение в стиле "человек обижен на технологию Х за то, что она не решила его проблемы в области У (хотя технология Х и не предназначена для этого)".
Обработать данные - да, вывести статичную страничку на основе данных - да, в конце концов одна из основных целей XML-XSLT-XPath - работать с структурированными данными, преобразовывать их в функциональном стиле. А генерацию динамичаских сложных страниц не стоит валить в эту кучу.
Неудивительно, что выбрав хрустальную вазу для забивания гвоздей через некоторое время убеждаешься, что молоток-то удобней. В Вашей статье основная часть описывает больше то, как забивали гвозди хрустальной вазой, и да, действительно неудобно, и куча недостатков. А вот в конце уже правильная мысль - технология должна быть к месту, но лучше задумываться об этом ДО начала создания проекта, "будет ли к месту технология А или Б", а не - "Возьмем технологию А" а через 6 месяцев - "технология А - г.но потому как не помогла нам в проекте".
А можно задать встречный вопрос - а что вы хотели сказать этой заметкой ? Что серебрянных пуль не бывает ? Я думаю 90% процентов посетителей Хабра это знают, читали Брукса. А дальше-то что ? "Не верьте рекламе" - ну тоже в общем-то Америку не открыли. Если честно - от текста у меня сложилось ощущение в стиле "человек обижен на технологию Х за то, что она не решила его проблемы в области У (хотя технология Х и не предназначена для этого)".
Да, я именно и хотел показать, что XML/XSLT желательно использовать именно для простых преобразований. А разве простые преобразования сложно сделать на PHP или ASP? Да нет, так же просто. Тогда вообще зачем в современных программных веб-системах использовать XML/XSLT и вводить в продукты и решения несколько технологий?
Аффтар, вы фееричны. Простые преобразования ага. =) Единственные реальный turing complete язык трансформаций прегоден исключительно для простых трансформаций, и единственный реальный формат обмена данными в SOA вообще не нужен потому что данные в вашем представлении, прошу прощения за тавтологию, представление от содержания отделить нереально. Самое главное что сейчас набегут похапе-кодеры и со всем согласятся.;-)
Удобство, скорость, простота и функциональный подход :). Да и не все, что так легко делается в xslt\xpath, также легко делается в PHP или даже в .NET (а тут еще и компилировать), да и парсер MSXML стоит на почти всех машинах с Windows (с IE6 идет вроде как) - а для PHP- нужен отдельный интерпретатор.
Каждая технология занимает свою нишу, и XML\XSLT свою нишу заняли, и плотно.
Зачастую XML\XSLT\XPath дополняют монотехнологичные решения, и дают свой выигрыш - в удобстве, в скорости, в гибкости. Если что-то можно сделать со значительно меньшими трудозатратами - почему бы и нет. Монотехнологичность это хорошо, но не это должно быть самоцелью проекта, это просто способ облегчить поддержку, снизить затраты и пр.
Каждая технология занимает свою нишу, и XML\XSLT свою нишу заняли, и плотно.
Зачастую XML\XSLT\XPath дополняют монотехнологичные решения, и дают свой выигрыш - в удобстве, в скорости, в гибкости. Если что-то можно сделать со значительно меньшими трудозатратами - почему бы и нет. Монотехнологичность это хорошо, но не это должно быть самоцелью проекта, это просто способ облегчить поддержку, снизить затраты и пр.
что в вашем понимании простые преобразования?
имхо, xml+xslt лучше всего использовать при работе с деревьями, притом несимметричными и сложной структурой(молчу уж о возможностях DOM для построения этих деревьев). Берем любой форум. Сколько нужно делать циклов(или рекурсий) чтобы вывести более-менее сложное построение. А с помощью xslt это решается за раз. Тот же смарти требует кодинга циклического вывода.
по поводу изменения дизайна: для переноса элементов в правильном построении кода меняется минимум, более того дизайн как правило меняется без изменения каких либо xslt операторов. Достаточно один раз разработать шаблон,дальше изменять его элементарно.
имхо, xml+xslt лучше всего использовать при работе с деревьями, притом несимметричными и сложной структурой(молчу уж о возможностях DOM для построения этих деревьев). Берем любой форум. Сколько нужно делать циклов(или рекурсий) чтобы вывести более-менее сложное построение. А с помощью xslt это решается за раз. Тот же смарти требует кодинга циклического вывода.
по поводу изменения дизайна: для переноса элементов в правильном построении кода меняется минимум, более того дизайн как правило меняется без изменения каких либо xslt операторов. Достаточно один раз разработать шаблон,дальше изменять его элементарно.
Спасибо за здоровый смех в конце рабочей недели. =) вы фееричны.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Главная трудность (и она же ценность XSLT) — это нетрадиционный (то бишь функциональный) подход к обработке текста. Многие айтишники затачивают мозг на процедурный подходи (грубо говоря), поэтому эффективно использовать XSLT не получается. Слишком сложная это технология, однако. Но умелая декомпозиция решает все проблемы, но это ой как тяжело.
П.С.
XPath — фантастически-гениальная вещь :)
П.С.
XPath — фантастически-гениальная вещь :)
Вот, наконец, достойный ответ от представителей лагеря XSLT. Если браться умеючи, то все работает нормально и быстро. И верстается комфортно.
Присоединяюсь ко всем вышевысказавшимся, начавшим комент с фразы "аффтар, вы фееричны". Дремучая некомпетентность.
Я думаю что выбор XSLT или шаблонизатор, в стиле Smarty, во многом зависит от того кому в дальнейшем сопровождать и поддерживать продукт. Если таковыми будут люди не слишком привыкшие к сложной логике и структуре данных, то выбор будет за шаблонизатором (Smarty), ну а если проект сопровождают программисты то выбор XSLT будет очень оправдан.
P.S. Все сказанное актуально для web-разработок
P.S. Все сказанное актуально для web-разработок
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Иллюзии XML/XSLT технологий