Вчера в пробке наблюдал товарища, который лихо рассекал по тротуарам на Segway. В принципе прикольная тема в свете нынешних московских реалий, вопрос только - где его заряжать?..
Согласен с комментаторами, считающими, что широкое использование данной технологии неоправдано. Да, есть вещи типа wikimapia.org - там идентификатор фрагмента используется действительно используется для определения фрагмента, только не страницы, а карты. Это нормально и в случае навигации по списку, разбитому на страницы (страница списка - это тоже как бы фрагмент). Логика при этом не страдает. Но грузить всю страницу через AJAX - это неоправданное усложнение кода и архитектуры (и, как следствие, снижение надёжности), лишняя нагрузка на сервер и на клиентскую машину. Не нужно бояться перезагрузить страницу в браузере.
Некрасиво, факт. Потому что всё остальное так или иначе заточено под формат "модуль-контроллер-действие", тогда как троичность этой конструкции весьма условна. Но делать нечего, корячимся...
2-3) "Криворукость" программиста обычно не связана с PHP как с инструментом. То есть этот же самый проект, будучи написанным на Руби или Питоне, тормозил бы точно так же и в тех же местах. Причём в основном - при выборке данных из СУБД. Ну, бывают ещё разные идиотские самопальные шаблонные системы, но это уже редкость.
7) Дело в том, что в большинстве случаев "тормознутость" sprintf реально никак не сказывается на общей производительности. Массивный контент сосредоточен в шаблонах, а вклад мелочёвки незначителен. Не, ну сдуру можно, конечно, и sprintf-ами сайт положить :)
8) "Потребности сайта" - штука комплексная и в общем случае включает в себя потребности программиста. Иногда дешевле взять хостинг подороже, чем оплачивать труды программиста, который научит сайт сносно пахать на плохом хостинге. Хотя это, конечно, не повод писать откровенную лажу в расчёте на суперкомпьютер, который всё перемелет...
9-10) О, это да :)
12) Написать провокационный пост и не измазаться при этом самому практически невозможно: вместе с изобличаемыми пороками обязательно всплывут и собственные, ггг :)
Да нет, скорее его просто достал непрекращающиеся повсеместно извержения религиозного характера на темы "похапэ - отстойный язык, юзайте руби/питон/перл" и про ловлю блох промеж кавычек с эхами. Местами, конечно, перегнул, но какая ж провокация без этого :)
В целом понравилось, несмотря на нарочито жёсткий стиль изложения. Хорошо подмечены ключевые болевые точки web-разработчика :)
Большой процент флеймов вокруг похапэ крутится именно вокруг микрооптимизаций: все эти кавычки, эхи и прочая лабуда. В реальных проектах bottleneck'ов, где всё это реально влияет на производительность, обычно не бывает.
По 5-му пункту: не всё так просто, обычно echo-подобные конструкции во множестве вызываются во view-скриптах (что в "PHP-шаблонах" ZF, что в Smarty). Другое дело, что гораздо раньше, чем различия в методиках вывода начнут сказываться на скорости вывода, начнутся проблемы с пропихиванием выведенного через канал.
Но вот со всякими там юниксами-акселераторами на рабочей машине - не согласен категорически. Это уже фанатизм. Большинство проектов пишутся как кроссплатформенные, так что работать надо в той операционке, в которой привычно. А акселератор на рабочем месте скорее вредит, потому как без него лучше видно, что какой-то код подтормаживает.
+1 Поисковые оптимизаторы именуются SEO, рекомендую автору исправить :)
В целом статья нормальная. Хоть это всё, казалось бы, и прописные истины - многим не помешает лишний раз прочитать.
«В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.»
Во! Золотые слова.
А основная проблема с XSLT лежит за его пределами - как раз в упомянутом вами представлении документа в формате XML. А защититься от дурака-программиста, к сожалению, намного сложнее, чем от дурака-верстальщика :)
Отмечу, что, расписывая недостатки Smarty, автор статьи не упомянул о реализованной в нём возможности запрета напрямую обращаться к PHP. Детский сад, имхо: "а в Smarty можно запрос к БД в шаблоне прописать", "а в XML можно каталог товаров запихнуть и всё затормозит"... Так сдуру-то можно и сами знаете что сломать :) На мой взгляд, тема в статье раскрыта чересчур однобоко.
Уже пользую RC вовсю.
Из заметного - лэйауты и вообще весь Enhanced Zend_View вошли в состав. Ещё Zend_Form появился, ещё не тестил, но, похоже, довольно удобная штука. Ещё появились инфлекторы, раньше их не замечал. Опять-таки пока не пробовал. Документацию сегодня свежую закачали.
Гради Буч. Объектно-ориентированный анализ и проектирование (с примерами приложений на С++)
7) Дело в том, что в большинстве случаев "тормознутость" sprintf реально никак не сказывается на общей производительности. Массивный контент сосредоточен в шаблонах, а вклад мелочёвки незначителен. Не, ну сдуру можно, конечно, и sprintf-ами сайт положить :)
8) "Потребности сайта" - штука комплексная и в общем случае включает в себя потребности программиста. Иногда дешевле взять хостинг подороже, чем оплачивать труды программиста, который научит сайт сносно пахать на плохом хостинге. Хотя это, конечно, не повод писать откровенную лажу в расчёте на суперкомпьютер, который всё перемелет...
9-10) О, это да :)
12) Написать провокационный пост и не измазаться при этом самому практически невозможно: вместе с изобличаемыми пороками обязательно всплывут и собственные, ггг :)
Большой процент флеймов вокруг похапэ крутится именно вокруг микрооптимизаций: все эти кавычки, эхи и прочая лабуда. В реальных проектах bottleneck'ов, где всё это реально влияет на производительность, обычно не бывает.
По 5-му пункту: не всё так просто, обычно echo-подобные конструкции во множестве вызываются во view-скриптах (что в "PHP-шаблонах" ZF, что в Smarty). Другое дело, что гораздо раньше, чем различия в методиках вывода начнут сказываться на скорости вывода, начнутся проблемы с пропихиванием выведенного через канал.
Но вот со всякими там юниксами-акселераторами на рабочей машине - не согласен категорически. Это уже фанатизм. Большинство проектов пишутся как кроссплатформенные, так что работать надо в той операционке, в которой привычно. А акселератор на рабочем месте скорее вредит, потому как без него лучше видно, что какой-то код подтормаживает.
В целом статья нормальная. Хоть это всё, казалось бы, и прописные истины - многим не помешает лишний раз прочитать.
Во! Золотые слова.
А основная проблема с XSLT лежит за его пределами - как раз в упомянутом вами представлении документа в формате XML. А защититься от дурака-программиста, к сожалению, намного сложнее, чем от дурака-верстальщика :)
Из заметного - лэйауты и вообще весь Enhanced Zend_View вошли в состав. Ещё Zend_Form появился, ещё не тестил, но, похоже, довольно удобная штука. Ещё появились инфлекторы, раньше их не замечал. Опять-таки пока не пробовал. Документацию сегодня свежую закачали.