Zend Framework 2 — долгожданные усовершенствования в Controller и View

[Ganesh]

Пардон, но не удержался: «7 вызовов вместо 13, думаю можно говорить о 90% ускорении» Вот это математика)

[nod]

Не проблема, заменил 90% на двух-кратное ускорение, чтоб глаз меньше резало. Математика проста, было грубо говоря 14 вызовов, стало 7 — в два раза возросла производительность.

[nod]

*двукратное

[red_pilot]

Вам какбе намекают, что в два раза — это на 50% быстрее.
На 90% быстрее — это значит, что было 10 секунд, а стало 1 секунду.
Ваш, КО.

[IIIEB4YK]

Задачка для третьего класса гик-школы:
Ваш код обрабатывал 1000 запросов в секунду. Затем вы его рефакторнули, и он стал на 50% быстрее. Сколько запросов в секунду стал обрабатываль ваш скрипт.
Ответ: 50% от 1000 = 500, следовательно, ваш код стал обрабатывать на 500 запросов в секунду больше. 1000 + 500 = 1500 запросов в секунду.
Задачка со звёздочкой: Сколько запросов станет обрабатывать ваш код при ускорении его ещё на 90%?

[noma4i]

Большинство гиков отчалило из класса, сразу после решения 1й задачки.
Гик != Отличник

[IIIEB4YK]

Ну, я не очень понимаю, что в моём сообщении привело вас к умозаключению, что я считаю гиков отличниками, но держите нас в курсе, да =)

[red_pilot]

Вы говорите о производительности, а не о быстроте выполнения. Подмена понятий.

Время выполнения одной операции — сек. (время)
Количество операций в секунду — оп/сек. (производительность, она же мощность в физике) (дробь тут очень важна)

Секунд на одну операцию: 1
Операция в секунду: 1

В два раза быстрее:
Секунд на операцию: 0.5
Операций в секунду: 2

Автор не пишет про ускорение, а не о приросте производительности.

PS: мощность — количество выполненой работы в единицу времени. Если бы вы вспомнили не о 3-ем классе, а хотябы о седьмом-восьмом, то точно бы осилили.

[red_pilot]

* Автор пишет про ускорение, а не о приросте производительности.

[STEVER]

какую тут крутую дискуссию завернули. все у автора было верно:
если производительность/скорость/ещечтото увеличилось в 2 раза — это значит на 100%,
если же почти в 2 раза — то можно написать на 90%

[IIIEB4YK]

точно бы осилили

лол, баттхёрт. ясно.

Вы говорите о производительности, а не о быстроте выполнения.

оО
Вы здоровы? Производительность и «быстрота», она же скорость, в текущем контексте есть одно и то же, и все они выражаются в «чем-то за время» (например, км/ч, лол/мин, оп/сек). А то, что вы выражаете в секундах, это время выполнения, и о нём ни в оригинальном сообщении, ни в вашем нет ни слова.

Автор пишет про ускорение, а не о приросте производительности.

Так, ускорение. Значит, меняется скорость, так? Скорость в чём измеряется? А, точно, это же то же самое, что и производительность в нашем контексте — оп/сек.
Перевожу на человеческий: ускорение на 90% значит, что скорость возросла на 90%, то есть, например, со 100 до 190 км/ч. Вот если бы речь шла об уменьшении какого-то показателя, то вы были бы правы — но увы и ах, об уменьшении речи нет, а уменьшение времени есть лишь следствие увеличения скорости (производительности), которое вы додумали и выпячиваете в попытке показать, быдто бы вы что-то там осилили.

[yuretsz]

Нет разницы увеличиваем или уменьшаем показатель. Ехали 100 км\ч замедлились на 90% — едем 100 — 90 = 10 км\ч.

[IIIEB4YK]

Я имел ввиду перевод из сложения/вычитания в умножение/деление, блестяще проведённый автором исходного комментария: «в два раза — это на 50% быстрее» — ну нормально, нет? =) А так-то вы правы, разумеется.

[yuretsz]

«в два раза — это на 50% быстрее» — ну нормально, нет? =)

Иногда кажется, что маркетологи тоже не видят разницы между «в два раза и на 50%» :)

[ezh]

А она есть?

[yuretsz]

Вы таки маркетолог?

[noma4i]

Долгожданным усовершенствованием будет превращение фронт контроллера в стейт машину, как было и заявлено еще года 4 назад.

Просто if/else конструкции монстрообразные уже. Не говоря о том, что в принципе все идет к этому. Сейчас в зенде уже фактически есть стейты — диспатч, роутинг. ПабСабы нам обещали когда? Я помню еще ЗендКонфу 2009 года в Питере, когда нам и анонсировали их.

[MikaMikuMik]

Спасибо за ссылки и за новость, интересно.

[1eon]

согласен.

[noma4i]

It will not be automatically escaped in view.

[noma4i]

В первом зенде ничего автоматом не эскейпилось во view.

[noma4i]

О чем ваш коммент понятно, я просто указал на текст, мол надо как в примере. Я просто забыл написать в конце слово «лопата».

[diamant]

Имхо, плохо, что стринги эскейпятся, а массивы стрингов — нет.
В запарке можно об этом позабыть, и если вдруг понадобится передать из контроллера два текста вместо одного, могут возникнуть проблемы:
Было:
return(array('text'=>'blabla'));
…
echo $text; // проблем нет

Задание, добавить несколько текстов:
return(array('text'=>array('blabla', 'foo')));
…
foreach($text as $txt) echo $txt; // нужно эскейпить

Как раз недавно столкнулся с похожей проблемой в typo3: при посте формы из скалярных параметров удалялись пехапешные эскейпы, а из массивов — нет.

[homm]

Действительно, это очень коряво. Во-первых, как вывести оригинальный текст? Анэскейпить, или передавать единственным элменетом массива? Во-вторых, намного полезнее было бы сделать шорткат для $this->escape(): q($text). С неймспейсами это как раз бы хорошо получилось.

[bladeofsteel]

По мне так самым вкусным в ZF2 стали DI и Events

[Davert]

Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…

А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.

[bladeofsteel]

Ну, есть они не только в Symfony2, и не в ней первой появились. Так что, видимо, и у симфонистов тоже были причины «изобретать велосипед»

> Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…

Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)

[zizop]

Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?

Они интегрируются друг с другом, как раз для того, чтобы не писать велосипеды. Например компонент Yml из Symfony есть и в нём, и в ZF, и в Doctrine. Это плохо? По-моему просто отлично, когда каждый занимается своим делом, а не пишет «свою CMS». Разве нет?

А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.

Нет, всё с точностью наоборот. Бренд — тот же, фреймворк совершенно другой. Начав с внедрения неймспейсов и фишек php 5.3 зендовцы вошли в раш и используют его преимущества на всю катушку. Основная цель — увеличение производительности. Вы сравните два Skeleton Application. Взять хотя бы диспетчеризацию, построенную на событиях и старый цикл диспетчеризации. Всё по другому, я бы сказал на новом уровне.

[bladeofsteel]

Вы не так поняли комент Davert-а. Он говорит о том, что есть уже симфони2 с Di, а зендовцы свой изобрели. И говоря о двух одинаковых фреймворках под разными брендами, он имеет в виду Symfony2 и ZF2, а не ZF1/ZF2

[zizop]

Понял, пардоньте. Ну у ZF и Symfony свои пути развития. Symfony — монолит, ZF — конструктор.

[Davert]

Вот именно. Вы полностью подтверждаете мои слова про бренды!

Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.

Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.

[zizop]

Да, я в курсе про Symfony components. Умный шаг. Идут в сторону конструктора, но всё же Symfony по своей природе именно монолит. ZF гораздо гибче и абстрактнее.
Про бренды полностью согласен. Такая фигня и с ZF, и с Symfony, и с Doctrine.

[Davert]

Ну насчет гибче абстрактнее… Symfony сейчас как раз и продвигается как компоненты.
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.

Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (

[bladeofsteel]

ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.

Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)

[Davert]

Не сравнивал их, так один в один.
Если сможете сравнить их в статье, буду крайне благодарен )

[yuretsz]

Symfony никогда не планировалась как монолитный фреймворк. Только на первом релизе это скорее выражалось в использовании сторонних компонентов, таких как Propel \ Doctrine, потом, после релиза версии 1.2 большой шаг к разделению был приход sfForm и теперь Symfony2 уже практически полностью состоит из разделенных компонентов.

[Davert]

Та не надо. Был достаточно жесткий каркас, аки Rails.
И компоненты, как ни крути, выпиливать приходилось из общего ядра.
Он был монолитным, но это было даже хорошо ) Каркас приложения не приходилось строить из кубиков.

[feedbee]

Не понимаю, зачем делать переменные в шаблоне локальными? Как их тогда отличать от реально локальных переменных в шаблоне? Я собственно так и привык ориентироваться? $this->x — параметр из контроллера, $x — локальная переменная, созданная в шаблоне. А теперь будет каша и мешанина.

А в чем плюсы, я так и не понял (надеюсь, что мы не считаем плюсом то, что нужно вводить на 7 символов меньше)?

[homm]

А их действительно нужно для чего-то отличать?

7 символов по 50 раз в шаблоне — явный плюс. Меньше визуального шума.

[feedbee]

Подсчет символов в коде — это последнее, что надо делать. Что касается 50 раз, то слабо себе представляю, где столько раз нужно обращаться к параметрам из одного шаблона. Чаще это наоборот 5—10 раз.

А по поводу необходимости отличия тут примерно то же самое, как и в случае отличия полей класса от локальных переменных метода. По сути — одно и то же.

[zizop]

Зачем? В виде должна быть логика представления, там вообще php кода должно быть по минимуму. Мне кажется, так гораздо лучше. Верстальщик опять же откроет вид или шаблон, и быстрее в него «въедет». И вообще есть такая штука, как ViewModel, в которой должны лежать подготовленные для вида данные.

[feedbee]

В виде должна быть логика представления (если это не Hello World). PHP-код — это как раз и есть логика представления. И ее должно быть ровно столько, сколько нужно. А верстальщики вроде должны шаблоны без логики делать, логика — задача программиста. Правда последнее утверждение может быть весьма спорным и наверняка найдутся куча примеров, когда программисты верстают или верстальщики пишут PHP-код в шаблонах.

Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.

[Davert]

По идее, в шаблоне не должно быть локальных переменных.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.

[feedbee]

По какой идеи?

Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.

Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.

[Davert]

«А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления)»

Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.

[feedbee]

А это утверждение на чем основано? Хэлперы вообще-то служат не для хранения кода, а для его повторного использования.

[Davert]

Все утверждения основаны на опыте и здравом смысле.

Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.

[feedbee]

чтд…

[Warlock2]

А это условие считается логикой?

if (!empty($entries)):
foreach ($entries as $item):
…
endforeach;
else:
echo «no entries»;
endif;

[zizop]

Классная статья, спасибо ;-)
Чувствуете, что ZF стал более удобнее, «человечнее» что-ли?
Такой вопрос, в первом ZF был большой оверхед на Zend_Application. Во втором вы случаем не тестировали Zend\Mvc\Application?

[nod]

Тестировать не тестировали. Но много где написано, что они все это дело переписали с нуля. И причиной тому была низкая производительность.

[ainu]

Интересует вопрос — чем локальные переменные идеологически и практически лучше в виде? Поддержка шаблонизаторов и короткий вывод в голом PHP коде шаблона?

То, что контроллер возвращает, а не сообщает, конечно, хорошо — тестировать гоораздо проще — сам понимаю. А сам способ использования такой чем лучше?

[nod]

Отвечу только с практической стороны, и это сугубо личная точка зрения.

Во вью-шаблонах про поддержку и короткий вывод я с вами согласен.
Добавлю:
— чище код, его проще поддерживать
— теперь хелперы сразу выделяются благодаря $this (в ZF1 мне эта каша хелперов и переменных просто кажется некрасивой)
— опять таки меньше магических вызовов (мысли вслух: хотя хм-м-м, а как они массив из контроллера в локальные переменные перевели? опять таки какая-то магия. надо будет посмотреть как они это реализовали.)

Вобщем во вью шаблонах это чисто эстетическое улучшение.

Про контроллеры:
— с тестированием абсолютно согласен
— избыточная связанность действий контроллера со вью-классом исчезла (надо писать в какой-то $this->view-> и опять какая-то ненужная тормознутость в использовании магических методов, вобщем некрасиво)
— они подготовили контроллеры к возможности навешивания событий к действиям контроллера через новый компонент EventManager (думаю это основная причина)
— ну и чисто для удобства, теперь можно прозрачно вызвать внутри одного метода/действия получить для обработки массив данных от другого метода/действия этого же класса (иногда такое требовалось и приходилось создавать приватный метод, который потом использовался по отдельности в двух методах).

[mayhem]

Перевести массив в набор переменных можно функцией extract. Интересно другое, если возвращать из контроллера данніе через return, все равно довольно часто придется создавать массив, и возвращать уже его, так как количесто вередаваеміх во view переменніх может біть разное (например в режиме администратора передать доп данные во view)

[nod]

Спасибо, про extract я совсем забыл )

Скорее всего в вашем случае «в режиме администратора передать доп данные во view» можно будет повешать событие на контроллер через EventManager.

Либо всегда передавать полный набор данных и во вью уже ограничивать вывод согласно правам доступа (в этом случае будьте аккуратны если пользуетесь AjaxContext'ом, а то все данные в json'е станут всем доступны).

[AndrewStephanoff]

Вроде как ещё обещали переработать механизм bootstrap'инга, потому что сейчас (ZF 1) bootstrap запускается для всех модулей.