Комментарии 59
Пардон, но не удержался: «7 вызовов вместо 13, думаю можно говорить о 90% ускорении» Вот это математика)
Вам какбе намекают, что в два раза — это на 50% быстрее.
На 90% быстрее — это значит, что было 10 секунд, а стало 1 секунду.
Ваш, КО.
На 90% быстрее — это значит, что было 10 секунд, а стало 1 секунду.
Ваш, КО.
Задачка для третьего класса гик-школы:
Ваш код обрабатывал 1000 запросов в секунду. Затем вы его рефакторнули, и он стал на 50% быстрее. Сколько запросов в секунду стал обрабатываль ваш скрипт.
Ответ: 50% от 1000 = 500, следовательно, ваш код стал обрабатывать на 500 запросов в секунду больше. 1000 + 500 = 1500 запросов в секунду.
Задачка со звёздочкой: Сколько запросов станет обрабатывать ваш код при ускорении его ещё на 90%?
Ваш код обрабатывал 1000 запросов в секунду. Затем вы его рефакторнули, и он стал на 50% быстрее. Сколько запросов в секунду стал обрабатываль ваш скрипт.
Ответ: 50% от 1000 = 500, следовательно, ваш код стал обрабатывать на 500 запросов в секунду больше. 1000 + 500 = 1500 запросов в секунду.
Задачка со звёздочкой: Сколько запросов станет обрабатывать ваш код при ускорении его ещё на 90%?
Большинство гиков отчалило из класса, сразу после решения 1й задачки.
Гик != Отличник
Гик != Отличник
Вы говорите о производительности, а не о быстроте выполнения. Подмена понятий.
Время выполнения одной операции — сек. (время)
Количество операций в секунду — оп/сек. (производительность, она же мощность в физике) (дробь тут очень важна)
Секунд на одну операцию: 1
Операция в секунду: 1
В два раза быстрее:
Секунд на операцию: 0.5
Операций в секунду: 2
Автор не пишет про ускорение, а не о приросте производительности.
PS: мощность — количество выполненой работы в единицу времени. Если бы вы вспомнили не о 3-ем классе, а хотябы о седьмом-восьмом, то точно бы осилили.
Время выполнения одной операции — сек. (время)
Количество операций в секунду — оп/сек. (производительность, она же мощность в физике) (дробь тут очень важна)
Секунд на одну операцию: 1
Операция в секунду: 1
В два раза быстрее:
Секунд на операцию: 0.5
Операций в секунду: 2
Автор не пишет про ускорение, а не о приросте производительности.
PS: мощность — количество выполненой работы в единицу времени. Если бы вы вспомнили не о 3-ем классе, а хотябы о седьмом-восьмом, то точно бы осилили.
* Автор пишет про ускорение, а не о приросте производительности.
точно бы осилилилол, баттхёрт. ясно.
Вы говорите о производительности, а не о быстроте выполнения.оО
Вы здоровы? Производительность и «быстрота», она же скорость, в текущем контексте есть одно и то же, и все они выражаются в «чем-то за время» (например, км/ч, лол/мин, оп/сек). А то, что вы выражаете в секундах, это время выполнения, и о нём ни в оригинальном сообщении, ни в вашем нет ни слова.
Автор пишет про ускорение, а не о приросте производительности.Так, ускорение. Значит, меняется скорость, так? Скорость в чём измеряется? А, точно, это же то же самое, что и производительность в нашем контексте — оп/сек.
Перевожу на человеческий: ускорение на 90% значит, что скорость возросла на 90%, то есть, например, со 100 до 190 км/ч. Вот если бы речь шла об уменьшении какого-то показателя, то вы были бы правы — но увы и ах, об уменьшении речи нет, а уменьшение времени есть лишь следствие увеличения скорости (производительности), которое вы додумали и выпячиваете в попытке показать, быдто бы вы что-то там осилили.
Нет разницы увеличиваем или уменьшаем показатель. Ехали 100 км\ч замедлились на 90% — едем 100 — 90 = 10 км\ч.
Долгожданным усовершенствованием будет превращение фронт контроллера в стейт машину, как было и заявлено еще года 4 назад.
Просто if/else конструкции монстрообразные уже. Не говоря о том, что в принципе все идет к этому. Сейчас в зенде уже фактически есть стейты — диспатч, роутинг. ПабСабы нам обещали когда? Я помню еще ЗендКонфу 2009 года в Питере, когда нам и анонсировали их.
Просто if/else конструкции монстрообразные уже. Не говоря о том, что в принципе все идет к этому. Сейчас в зенде уже фактически есть стейты — диспатч, роутинг. ПабСабы нам обещали когда? Я помню еще ЗендКонфу 2009 года в Питере, когда нам и анонсировали их.
Спасибо за ссылки и за новость, интересно.
НЛО прилетело и опубликовало эту надпись здесь
Имхо, плохо, что стринги эскейпятся, а массивы стрингов — нет.
В запарке можно об этом позабыть, и если вдруг понадобится передать из контроллера два текста вместо одного, могут возникнуть проблемы:
Было:
return(array('text'=>'blabla'));
…
echo $text; // проблем нет
Задание, добавить несколько текстов:
return(array('text'=>array('blabla', 'foo')));
…
foreach($text as $txt) echo $txt; // нужно эскейпить
Как раз недавно столкнулся с похожей проблемой в typo3: при посте формы из скалярных параметров удалялись пехапешные эскейпы, а из массивов — нет.
В запарке можно об этом позабыть, и если вдруг понадобится передать из контроллера два текста вместо одного, могут возникнуть проблемы:
Было:
return(array('text'=>'blabla'));
…
echo $text; // проблем нет
Задание, добавить несколько текстов:
return(array('text'=>array('blabla', 'foo')));
…
foreach($text as $txt) echo $txt; // нужно эскейпить
Как раз недавно столкнулся с похожей проблемой в typo3: при посте формы из скалярных параметров удалялись пехапешные эскейпы, а из массивов — нет.
По мне так самым вкусным в ZF2 стали DI и Events
Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Ну, есть они не только в Symfony2, и не в ней первой появились. Так что, видимо, и у симфонистов тоже были причины «изобретать велосипед»
> Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)
> Ну честно, если бы добавили новые компоненты, или какие-то интересные архитектурные решения…
Хм… архитектуру ZF практически полностью переписали, Вам этого мало?! :)
Они уже и так есть в Symfony2. Интересно, чего Зендовцы переписывают велосипеды?
Они интегрируются друг с другом, как раз для того, чтобы не писать велосипеды. Например компонент Yml из Symfony есть и в нём, и в ZF, и в Doctrine. Это плохо? По-моему просто отлично, когда каждый занимается своим делом, а не пишет «свою CMS». Разве нет?
А то сейчас получится 2 почти идентичных фреймворка с похожими возможностями.
Отличия только в бренде.
Нет, всё с точностью наоборот. Бренд — тот же, фреймворк совершенно другой. Начав с внедрения неймспейсов и фишек php 5.3 зендовцы вошли в раш и используют его преимущества на всю катушку. Основная цель — увеличение производительности. Вы сравните два Skeleton Application. Взять хотя бы диспетчеризацию, построенную на событиях и старый цикл диспетчеризации. Всё по другому, я бы сказал на новом уровне.
Вы не так поняли комент Davert-а. Он говорит о том, что есть уже симфони2 с Di, а зендовцы свой изобрели. И говоря о двух одинаковых фреймворках под разными брендами, он имеет в виду Symfony2 и ZF2, а не ZF1/ZF2
Понял, пардоньте. Ну у ZF и Symfony свои пути развития. Symfony — монолит, ZF — конструктор.
Вот именно. Вы полностью подтверждаете мои слова про бренды!
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
Вы не заметили, что Симфони2 уже далеко не монолит, а тоже набор компонентов, и наверное, даже более независимых. Посмотрите немного на Symfony2, и на Symfony Components.
Проблема в том, что в Симфони под единым названием существут 2 разных фреймворка и не все ещё это знают.
Да, я в курсе про Symfony components. Умный шаг. Идут в сторону конструктора, но всё же Symfony по своей природе именно монолит. ZF гораздо гибче и абстрактнее.
Про бренды полностью согласен. Такая фигня и с ZF, и с Symfony, и с Doctrine.
Про бренды полностью согласен. Такая фигня и с ZF, и с Symfony, и с Doctrine.
Ну насчет гибче абстрактнее… Symfony сейчас как раз и продвигается как компоненты.
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
Вон уже 8ой друпал будет их использовать. В чем там монолитность пока непонятно. ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Вообщем, у меня есть некоторое разочарование. Я надеялся, что в Зенде будут какие-то новые оригинальные архитектурные решения. А их нет (
ВЗять те же бандлы… Они намного менее привязаны к конкретному проекту, чем что либо в Зенде.
Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
Модули ZF2 смотрели? Теже бандлы. Можно реализовать специфическую для проекта функциональность, а можно решать общую задачу (уже появилась куча модулей этим занимающихся, например, реализация регистрации/авторизации пользователей)
Symfony никогда не планировалась как монолитный фреймворк. Только на первом релизе это скорее выражалось в использовании сторонних компонентов, таких как Propel \ Doctrine, потом, после релиза версии 1.2 большой шаг к разделению был приход sfForm и теперь Symfony2 уже практически полностью состоит из разделенных компонентов.
Не понимаю, зачем делать переменные в шаблоне локальными? Как их тогда отличать от реально локальных переменных в шаблоне? Я собственно так и привык ориентироваться? $this->x — параметр из контроллера, $x — локальная переменная, созданная в шаблоне. А теперь будет каша и мешанина.
А в чем плюсы, я так и не понял (надеюсь, что мы не считаем плюсом то, что нужно вводить на 7 символов меньше)?
А в чем плюсы, я так и не понял (надеюсь, что мы не считаем плюсом то, что нужно вводить на 7 символов меньше)?
А их действительно нужно для чего-то отличать?
7 символов по 50 раз в шаблоне — явный плюс. Меньше визуального шума.
7 символов по 50 раз в шаблоне — явный плюс. Меньше визуального шума.
Подсчет символов в коде — это последнее, что надо делать. Что касается 50 раз, то слабо себе представляю, где столько раз нужно обращаться к параметрам из одного шаблона. Чаще это наоборот 5—10 раз.
А по поводу необходимости отличия тут примерно то же самое, как и в случае отличия полей класса от локальных переменных метода. По сути — одно и то же.
А по поводу необходимости отличия тут примерно то же самое, как и в случае отличия полей класса от локальных переменных метода. По сути — одно и то же.
Зачем? В виде должна быть логика представления, там вообще php кода должно быть по минимуму. Мне кажется, так гораздо лучше. Верстальщик опять же откроет вид или шаблон, и быстрее в него «въедет». И вообще есть такая штука, как ViewModel, в которой должны лежать подготовленные для вида данные.
В виде должна быть логика представления (если это не Hello World). PHP-код — это как раз и есть логика представления. И ее должно быть ровно столько, сколько нужно. А верстальщики вроде должны шаблоны без логики делать, логика — задача программиста. Правда последнее утверждение может быть весьма спорным и наверняка найдутся куча примеров, когда программисты верстают или верстальщики пишут PHP-код в шаблонах.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.
Зачем разделять локальные и глобальные переменные в шаблоне я написал выше.
По идее, в шаблоне не должно быть локальных переменных.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.
Откуда они там возьмутся? Только из циклов. Вообщем, локальных переменных стоит избегать.
По какой идеи?
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
Да, в первую очередь локальные переменные появятся в циклах. А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления), и их результатам самое место в локальных переменных.
Что касается избегания, то это как минимум ничем не обосновано. Локальные переменные нужны как хотя бы потому, что они делают блоки кода чище.
«А вообще, в шаблоне могут быть вычисления (которые связаны с логикой представления)»
Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.
Та нет же, любые вычисления — это уже не представление. Их нужно выносить в хэлперы.
А это утверждение на чем основано? Хэлперы вообще-то служат не для хранения кода, а для его повторного использования.
Все утверждения основаны на опыте и здравом смысле.
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
Если есть догма «хэлперы для повторного использования» то не верьте ей. Используйте их там где это необходимо. Переносить логику в шаблоны необходимости нет. Точно так же, как сейчас не принято писать яваскрипт в шаблонах, или пардон, SQL-запросы, точно так же, следует выводить любую логику за рамки html-кода. Если так не делать, до говнокода останется всего полшага.
Классная статья, спасибо ;-)
Чувствуете, что ZF стал более удобнее, «человечнее» что-ли?
Такой вопрос, в первом ZF был большой оверхед на Zend_Application. Во втором вы случаем не тестировали Zend\Mvc\Application?
Чувствуете, что ZF стал более удобнее, «человечнее» что-ли?
Такой вопрос, в первом ZF был большой оверхед на Zend_Application. Во втором вы случаем не тестировали Zend\Mvc\Application?
Интересует вопрос — чем локальные переменные идеологически и практически лучше в виде? Поддержка шаблонизаторов и короткий вывод в голом PHP коде шаблона?
То, что контроллер возвращает, а не сообщает, конечно, хорошо — тестировать гоораздо проще — сам понимаю. А сам способ использования такой чем лучше?
То, что контроллер возвращает, а не сообщает, конечно, хорошо — тестировать гоораздо проще — сам понимаю. А сам способ использования такой чем лучше?
Отвечу только с практической стороны, и это сугубо личная точка зрения.
Во вью-шаблонах про поддержку и короткий вывод я с вами согласен.
Добавлю:
— чище код, его проще поддерживать
— теперь хелперы сразу выделяются благодаря $this (в ZF1 мне эта каша хелперов и переменных просто кажется некрасивой)
— опять таки меньше магических вызовов (мысли вслух: хотя хм-м-м, а как они массив из контроллера в локальные переменные перевели? опять таки какая-то магия. надо будет посмотреть как они это реализовали.)
Вобщем во вью шаблонах это чисто эстетическое улучшение.
Про контроллеры:
— с тестированием абсолютно согласен
— избыточная связанность действий контроллера со вью-классом исчезла (надо писать в какой-то $this->view-> и опять какая-то ненужная тормознутость в использовании магических методов, вобщем некрасиво)
— они подготовили контроллеры к возможности навешивания событий к действиям контроллера через новый компонент EventManager (думаю это основная причина)
— ну и чисто для удобства, теперь можно прозрачно вызвать внутри одного метода/действия получить для обработки массив данных от другого метода/действия этого же класса (иногда такое требовалось и приходилось создавать приватный метод, который потом использовался по отдельности в двух методах).
Во вью-шаблонах про поддержку и короткий вывод я с вами согласен.
Добавлю:
— чище код, его проще поддерживать
— теперь хелперы сразу выделяются благодаря $this (в ZF1 мне эта каша хелперов и переменных просто кажется некрасивой)
— опять таки меньше магических вызовов (мысли вслух: хотя хм-м-м, а как они массив из контроллера в локальные переменные перевели? опять таки какая-то магия. надо будет посмотреть как они это реализовали.)
Вобщем во вью шаблонах это чисто эстетическое улучшение.
Про контроллеры:
— с тестированием абсолютно согласен
— избыточная связанность действий контроллера со вью-классом исчезла (надо писать в какой-то $this->view-> и опять какая-то ненужная тормознутость в использовании магических методов, вобщем некрасиво)
— они подготовили контроллеры к возможности навешивания событий к действиям контроллера через новый компонент EventManager (думаю это основная причина)
— ну и чисто для удобства, теперь можно прозрачно вызвать внутри одного метода/действия получить для обработки массив данных от другого метода/действия этого же класса (иногда такое требовалось и приходилось создавать приватный метод, который потом использовался по отдельности в двух методах).
Перевести массив в набор переменных можно функцией extract. Интересно другое, если возвращать из контроллера данніе через return, все равно довольно часто придется создавать массив, и возвращать уже его, так как количесто вередаваеміх во view переменніх может біть разное (например в режиме администратора передать доп данные во view)
Спасибо, про extract я совсем забыл )
Скорее всего в вашем случае «в режиме администратора передать доп данные во view» можно будет повешать событие на контроллер через EventManager.
Либо всегда передавать полный набор данных и во вью уже ограничивать вывод согласно правам доступа (в этом случае будьте аккуратны если пользуетесь AjaxContext'ом, а то все данные в json'е станут всем доступны).
Скорее всего в вашем случае «в режиме администратора передать доп данные во view» можно будет повешать событие на контроллер через EventManager.
Либо всегда передавать полный набор данных и во вью уже ограничивать вывод согласно правам доступа (в этом случае будьте аккуратны если пользуетесь AjaxContext'ом, а то все данные в json'е станут всем доступны).
Вроде как ещё обещали переработать механизм bootstrap'инга, потому что сейчас (ZF 1) bootstrap запускается для всех модулей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Zend Framework 2 — долгожданные усовершенствования в Controller и View