Я и не спорю, что есть задачи, когда XSLT — подходящий инструмент. Например, выдача Яндекса, которая может показываться на самом Яндексе, а может отдаваться через Яндекс.XML. В таких случаях это действительно оправдано. Но когда речь идет о не очень больших сайтах, для которых нету необходимости все выходные данные предоставлять в нескольких форматах, я не вижу ни одной причины для использования XSLT. А таких сайтов в Интернете, наверное, 95%.
И только тот факт, что XSLT универсален и стандартизован, не делает его лучшим решением во всех случаях.
Мало того, что символов втрое больше, так это и выглядит совершенно нечитаемо для верстальщика. И это самая простейшая задача. Что в этом удобного? Ну или я не знаю, я не специалист по XSLT, может быть это проще сделать можно?
И еще такой вопрос: в цепочке «данные -> XML -> HTML» для чего нужен XML? Только для того, чтобы можно было воспользоваться XSLT? Все это, повторюсь, попахивает несоответствием инструмента задаче.
Я не говорю, что XSLT — какой-то сверхнепонятный язык, который кто-то не в состоянии постичь; в любой технологии можно разобраться, затратив на это определенное время, и после этого она перестанет казаться непонятной. Суть моих претензий, во-первых, в несоразмерности задачи и усилий, затрачиваемых на знакомство с технологией, во-вторых, в синтаксической и семантической избыточности XSLT при использовании в шаблонах сайтов, а в-третьих, в несоответствии технологии задаче (зачем мне XSLT, если у меня нет XML, а есть реляционная БД?)
Я тоже тестами лично не занимался, но здравый смысл мне подсказывает, что разбирать и исполнять конструкции шаблонных языков куда проще, чем XSLT.
Скажите лучше что-нибудь по другим пунктам. Что в нем удобного-то? Он избыточно сложный и избыточно универсальный для такой задачи. Когда вам надо сделать список покупок в магазине, вы его в TeX верстаете, а потом заказываете печать в офсетной типографии?
Вы что, шутите? Это, получается, дизайнеру-верстальщику надо учить XSLT, который на порядок сложнее любого шаблонного языка, а программисту в контроллере генерировать XML (исключительно для того, чтобы потом с помощью XSLT его преобразовать в HTML). Да и само преобразование — процесс не особенно быстрый. И ради чего все это?
Искренне не понимаю людей, которые пытаются продвигать XSLT в качестве замены шаблонизаторам.
Вы явно чего-то не понимаете. Популярность проекта не может характеризовать качество его программирования. О качестве кода вконтакте нам может что-то сказать, к примеру, огромное количество глупейших дыр на сайте, многие из которых до сих пор не залатаны.
Интересно, нафига нужна такая игрушка, если за те деньги, что она будет стоить, наверняка можно будет купить субноутбук на Атоме и простенький телефон чтоб говорить и в интернет выходить? :)
На самом деле не ломает — есть же целые сообщества, где все люди общаются абсолютно анонимно, т.е. даже не подписываясь. И им это нисколько не мешает обсуждать любые темы, хотя, конечно, троллей там предостаточно.
Как выяснилось, у нас с вами разные понятия об анонимности :)
Я под анонимностью понимаю отделение реальной личности от виртуальной, а не отсутствие какой-либо подписи вообще. Хотя особой разницы между этими случаями я, как и centur, не вижу.
Не вижу логики, когда минусуют за что-то, то минусуют комментарий и вы отлично видите, где вы неправы. А когда карму понижают — зачем знать, кто это сделал? Чтобы тоже в карму насрать? Или чтоб найти и "лицо сломать", как ниже пишут? :D
Да нет же, искренность — это искренность, и неважно, что за ней скрывается (вовсе не только гадости). Всегда лучше слышать от человека правду, если даже она неприятная. Мир, где все друг друга любят — это утопия, скучная к тому же.
Я, кстати, не пытаюсь оправдать первонахов. Речь идет о том, что анонимность дает свободу, которая, впрочем, и негативную сторону имеет.
Анонимность - это одно из главных достоинств интернета. Когда человек анонимен, они пишет то, что думает.
Когда же он пишет от своего имени, и не дай боже, оставляет еще и свои координаты, он чаще всего вынужден становиться скучным снобом. Он старается так переиначить свою мысль, чтобы никого не оскорбить, чтобы не обидеть какую-нибудь социальную группу, чтобы не нарушить закон, в конце концов.
Аналогия: вспомните любое выступление современных политиков по телевидению — ведь вы же не думаете всерьез, что вся эта мишура — их настоящие мысли? Как и любой человек, они могут кого-то ненавидеть, но никогда не заявят об этом вслух, потому что это неполиткорректно.
Искренность и персонификация обычно плохо друг с другом уживаются, потому что никто не хочет иметь лишние проблемы и портить свою репутацию.
По поводу Behavior-ов: в Доктрине есть реализация Nested Set, а также Class Templates с набором готовых шаблонов. Ну, плагины, ориентированные на пропел - да, тут сложно поспорить. Хорошо, что хотя бы sfGuard портирован. Остальные в общем-то не так уж и нужны (либо не используют пропел).
Если так рассуждать - кодеигнитер вообще в разы быстрее чем симфони с пропелом. Почему же ты тогда все равно выбрал симфони?
Я хочу сказать, что скорость исполнения не всегда должна быть решающим фактором при выборе инструмента. В каких-то случаях это оправдано, конечно (во всяких системах с высокой нагрузкой), но чаще выгоднее использовать инструмент, экономящий время разработки и потом уже при необходимости оптимизировать скорость (кэшированием, акслераторами и т.п.)
Согласно вышеприведенной ссылке разница в быстродействии с Пропелом незначительная — 6-7 против 9 — это даже не в два раза разница. То есть если скорость работы ORM станет ограничивающим фактором при быстродействии, то замена Доктрины на Пропел не спасет совершенно, придется применять какие-то радикальные меры, вроде кэширования.
Вот, и учитывая, что деньги, сэкономленные на времени разработки при использовании Доктрины, явно перевешивают деньги, затраченные на небольшое замедление работы, зачем спорить, что Доктрина лучше с Симфони? :)
Ну, например, об этом говорит тот факт, что в свн у доктрины последняя ревизия - 3892, а у пропела - 978. Вообще, я неправильно выразился, наверное. Я имел в виду, что она функциональнее и ближе к полноценному ORM, чем Пропел, и что разработка Доктрины ведется активнее.
По ссылке в блоге написано почти то же самое, что и я написал :)
А 11 строк кода, чтобы реализовать запрос в полторы строчки я не знаю как еще охарактеризовать, по-моему, "неприемлимо" — вполне подходит :)
На самом деле проблема Propel-а (ну и Apache Torque тоже, соответственно) в том, что они пытаются совершенно абстрагироваться от базы данных, чтобы программист работал только с объектами. А такой подход работает только для простых моделей, потому что реляционные БД и ООП - это все-таки сильно разные вещи.
Тормознутость доктрины (что, впрочем, спорно, я сам никаких сведений на эту тему не имею) компенсируется поддержкой кэширования, например.
И только тот факт, что XSLT универсален и стандартизован, не делает его лучшим решением во всех случаях.
Нормальный шаблонизатор:
{% for item in items %}
* {{ item }}
{% endfor %}
XSLT:
<xsl:template match=«items»>
<xsl:apply-templates/>
</xsl:template>
<xsl:template match=«item»>
* <xsl:apply-templates/>
</xsl:template>
Мало того, что символов втрое больше, так это и выглядит совершенно нечитаемо для верстальщика. И это самая простейшая задача. Что в этом удобного? Ну или я не знаю, я не специалист по XSLT, может быть это проще сделать можно?
И еще такой вопрос: в цепочке «данные -> XML -> HTML» для чего нужен XML? Только для того, чтобы можно было воспользоваться XSLT? Все это, повторюсь, попахивает несоответствием инструмента задаче.
Я не говорю, что XSLT — какой-то сверхнепонятный язык, который кто-то не в состоянии постичь; в любой технологии можно разобраться, затратив на это определенное время, и после этого она перестанет казаться непонятной. Суть моих претензий, во-первых, в несоразмерности задачи и усилий, затрачиваемых на знакомство с технологией, во-вторых, в синтаксической и семантической избыточности XSLT при использовании в шаблонах сайтов, а в-третьих, в несоответствии технологии задаче (зачем мне XSLT, если у меня нет XML, а есть реляционная БД?)
Скажите лучше что-нибудь по другим пунктам. Что в нем удобного-то? Он избыточно сложный и избыточно универсальный для такой задачи. Когда вам надо сделать список покупок в магазине, вы его в TeX верстаете, а потом заказываете печать в офсетной типографии?
Искренне не понимаю людей, которые пытаются продвигать XSLT в качестве замены шаблонизаторам.
Я под анонимностью понимаю отделение реальной личности от виртуальной, а не отсутствие какой-либо подписи вообще. Хотя особой разницы между этими случаями я, как и centur, не вижу.
Я, кстати, не пытаюсь оправдать первонахов. Речь идет о том, что анонимность дает свободу, которая, впрочем, и негативную сторону имеет.
Когда же он пишет от своего имени, и не дай боже, оставляет еще и свои координаты, он чаще всего вынужден становиться скучным снобом. Он старается так переиначить свою мысль, чтобы никого не оскорбить, чтобы не обидеть какую-нибудь социальную группу, чтобы не нарушить закон, в конце концов.
Аналогия: вспомните любое выступление современных политиков по телевидению — ведь вы же не думаете всерьез, что вся эта мишура — их настоящие мысли? Как и любой человек, они могут кого-то ненавидеть, но никогда не заявят об этом вслух, потому что это неполиткорректно.
Искренность и персонификация обычно плохо друг с другом уживаются, потому что никто не хочет иметь лишние проблемы и портить свою репутацию.
Я хочу сказать, что скорость исполнения не всегда должна быть решающим фактором при выборе инструмента. В каких-то случаях это оправдано, конечно (во всяких системах с высокой нагрузкой), но чаще выгоднее использовать инструмент, экономящий время разработки и потом уже при необходимости оптимизировать скорость (кэшированием, акслераторами и т.п.)
Вот, и учитывая, что деньги, сэкономленные на времени разработки при использовании Доктрины, явно перевешивают деньги, затраченные на небольшое замедление работы, зачем спорить, что Доктрина лучше с Симфони? :)
А 11 строк кода, чтобы реализовать запрос в полторы строчки я не знаю как еще охарактеризовать, по-моему, "неприемлимо" — вполне подходит :)
На самом деле проблема Propel-а (ну и Apache Torque тоже, соответственно) в том, что они пытаются совершенно абстрагироваться от базы данных, чтобы программист работал только с объектами. А такой подход работает только для простых моделей, потому что реляционные БД и ООП - это все-таки сильно разные вещи.
Тормознутость доктрины (что, впрочем, спорно, я сам никаких сведений на эту тему не имею) компенсируется поддержкой кэширования, например.