Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 115
То есть они там настолько все намудрили, что один факт работы с Зендом делает тебя героем.
Ок.
Ок.
А судя по первой картинке, ZF2, видимо, должен ассоциироваться с неуклюжим зелёным слоником :-D
Сколько себя помню, это же говорили и про всю первую ветку.
Честно говоря, большой опыт работы с первым зендом оказался у меня бессилен перед новой структурой MVC во втором. Ребята круты конечно, но назвать теперь фреймворк easy & intutive теперь нельзя.
Так и первый не был. Я сейчас в нем более-менее ориентируюсь — да, действительно, крутая штука. Но пока не пришло вот это понимание логики работы, парадигмы, что ли — просто кромешное болото какое-то.
Вроде того что вот есть у тебя форма и хочется тебе туда 1 сраный тэг добавить. А ты бьешься с декораторами полдня, пытаясь понять, почему когда 1 тэг добавляется, второй исчезает :-).
Со вторым, видимо, придется заново переживать этот адаптационный период беспросветного ужаса, чтобы потом наслаждаться легкостью и воздушностью :-).
Вроде того что вот есть у тебя форма и хочется тебе туда 1 сраный тэг добавить. А ты бьешься с декораторами полдня, пытаясь понять, почему когда 1 тэг добавляется, второй исчезает :-).
Со вторым, видимо, придется заново переживать этот адаптационный период беспросветного ужаса, чтобы потом наслаждаться легкостью и воздушностью :-).
насчет форм — да, одно из первых что пришлось сделать — добавить в проект PlainHtml декоторатор и фигачить туда прямой код… актуально когда надо посередине НУ ООЧЕНЬ типовой формы какой-то дизайнерский текст всобачить, и нехота для него элемент городить. но зато уже освоив Forms я уже влюбился в них) orm, scaffolding+беспросветная гибкость, до спуска вниз…
Composer, а не compositor.
Ну все.
Ждем статей «ZF2 для начинающих», «Zend Framework 2: мнение начинающего разработчика» и тэ дэ
Ждем статей «ZF2 для начинающих», «Zend Framework 2: мнение начинающего разработчика» и тэ дэ
Что ж они так долго делали, что в 2012 году роутинг у них выглядит так?
А ведь и правда, получается: «We hear Symfony doesn't have this problem».
'router' => array(
'routes' => array(
'album' => array(
'type' => 'segment',
'options' => array(
'route' => '/album[/:action][/:id]',
'constraints' => array(
'action' => '[a-zA-Z][a-zA-Z0-9_-]*',
'id' => '[0-9]+',
),
'defaults' => array(
'controller' => 'Album\Controller\Album',
'action' => 'index',
),
),
),
),
),
А ведь и правда, получается: «We hear Symfony doesn't have this problem».
Если это правда, я пожалуй и дальше буду писать на Kohana и ждать Zend Framework 3
Замените php-array нотацию на json нотацию. Будет чуть менее уродливо.
А зачем делать массу лишних вызовов? Всё равно ведь внутренняя структура аналогична этой.
>>>ресурс = view + list + edit + update + new + create + delete с параметрами для них по умолчанию
Почему все рубисты в этом посте жалуются на то, что роутер зенда — это не роутер РоР? Да, он действительно другой, но почему это считается за минус?
И да, не обязательно описывать каждый суброут по отдельности, достаточно написать один раз и пользоваться для любого ресурса — habrahabr.ru/post/150984/#comment_5120061
Но этот маршрут нужен только любителям РоР, так что его нет в дефолтной поставке.
Почему все рубисты в этом посте жалуются на то, что роутер зенда — это не роутер РоР? Да, он действительно другой, но почему это считается за минус?
И да, не обязательно описывать каждый суброут по отдельности, достаточно написать один раз и пользоваться для любого ресурса — habrahabr.ru/post/150984/#comment_5120061
Но этот маршрут нужен только любителям РоР, так что его нет в дефолтной поставке.
К хорошему быстро привыкаешь). Вот это gist.github.com/3673818 почти во всех фреймворках будет в пять раз длиннее и непонятнее, а еще никаким рест пахнуть даже отдаленно не будет. Руби силен своими dsl и здесь очень высоко ценится автоматизация. При этом среди разработчиков которые не использовали рельсы бытует мнение что «раз там все вот так, значит он трудно кастомизириуется и подходит только для ограниченного круга задач». Что является абсолютным заблуждением.
Не буду ни о чем спорить и прекрасно понимаю что все тоже самое можно в том или ином виде реализовать и в зенде (с поправкой на то то php не ruby) и более того я это делал правда для выборок.
Не буду ни о чем спорить и прекрасно понимаю что все тоже самое можно в том или ином виде реализовать и в зенде (с поправкой на то то php не ruby) и более того я это делал правда для выборок.
Хорошее это или плохое — это дело вкуса, но никак не объективных плюсов или минусов подхода. Мне, например, такой подход в принципе не нравится, так что то, что его нет в стандартной поставке — плюс. А те, кому он нужен, потратят 3 минуты своего времи и сами его реализуют.
Рельсы — набор хорошо скомпонованных и подогнаных друг к другу спорных решений. Если в целом ты не против этих решений (взять тот же ActiveRecord, например) — то рельсы дают много плюшек и сильно сокращают время разработки. Но если ты против какого-то из них — усилия на изменение будут гораздо выше, чем в том же зенде.
В общем рельсы решают частный случай какой-то проблемы, зенд — решает общий случай, а частности оставляет за программистом.
Рельсы — набор хорошо скомпонованных и подогнаных друг к другу спорных решений. Если в целом ты не против этих решений (взять тот же ActiveRecord, например) — то рельсы дают много плюшек и сильно сокращают время разработки. Но если ты против какого-то из них — усилия на изменение будут гораздо выше, чем в том же зенде.
В общем рельсы решают частный случай какой-то проблемы, зенд — решает общий случай, а частности оставляет за программистом.
Да хоть yaml, который выглядит гораздо лаконичнее всего остального. Это ужасно. Это ужасно настолько, насколько это вообще может быть ужасно
Как бы вы хотели написать этот же маршрут? Можно пример в коде?
Можно, например: www.playframework.org/documentation/2.0.3/JavaRouting, игрался правда недолго, но в целом очень приятные впечатления.
Конфиги «из коробки» можно вести в Ini-файлах, XML-е, YAML-е, JSON-е ну и как видите на чистом PHP (разумеется так работает быстрее).
Похожим образом описываются не только роуты, но другие настройки вашего проекта. К этому очень быстро привыкаешь. До недавнего времени была большая проблема с докой к компонентам и разобраться как правильно писать конфиги можно было только по рабочим примерам. Сейчас же я вижу нормальную доку.
Не пугайтесь, все намного проще чем кажется! :)
Похожим образом описываются не только роуты, но другие настройки вашего проекта. К этому очень быстро привыкаешь. До недавнего времени была большая проблема с докой к компонентам и разобраться как правильно писать конфиги можно было только по рабочим примерам. Сейчас же я вижу нормальную доку.
Не пугайтесь, все намного проще чем кажется! :)
Не буду говорить как там устроены конфиги, но по идее, даже если они в YAML, то при первом обращении скрипта к конфигам, они должны ложится в виде PHP массива в кэш и повторно читаться уже из кэша в готовом виде без преобразования. Это как пример. На производительность влиять не должно.
Ведение настроек в YAML тормозили проект раз в 10. Я честно тогда был в ступоре, как же хреново нужно написать парсер yaml…
Однажды на хабре уже развенчали миф про то, что конфиг на чистом php быстрее habrahabr.ru/post/112402/. Ini-файлы и JSON быстрее массивов на PHP.
Прошу заметить, что стандартный парсинг ini-файлов предполагает максимальную вложенность массива 2го уровня, т.е. [секция] [ключ]=[значение] нежели стандартный массив
ключ.третьего.уровня = значение
1. a.ini файл
2. вводим команду
3. получаем
4. идем читать документацию parse_ini_file()
[a]
b.c.d=e
2. вводим команду
$php -r "var_dump(parse_ini_file('a.ini',true));"
3. получаем
array(1) {
["a"]=>
array(1) {
["b.c.d"]=>
string(1) "e"
}
}
4. идем читать документацию parse_ini_file()
Ради интереса — посмотрите сэмпловый пример обычного java веб-приложения (минимум функционала- Spring MVC + Hibernate), и вы поймете что Zend не так уж и сложен =)
Или можно посмотреть на приложения на Play 2.0 или Play 1.2. ;-)
Не соглашусь с вами, спринговый экземпл mvc + hibernate пишется довольно просто и кратко.
Вы уж простите, но я смотрел и не пойму чем он сложнее? Один стандартынй web.xml, один стандартный spring-context.xml и все. Можно подробнее про сложности обычного Java приложения?
Ок- возьмем по минимуму
web.xml + servlet-context&root-context, log4j, hibernate.cfg. Ну и да, pom.xml незабудем.
Это по части конфигурации проекта только.
Я не утверждаю, что java однозначно сложнее php (во многих случаях даже наоборот), но как минимум стэк технологий шире
web.xml + servlet-context&root-context, log4j, hibernate.cfg. Ну и да, pom.xml незабудем.
Это по части конфигурации проекта только.
Я не утверждаю, что java однозначно сложнее php (во многих случаях даже наоборот), но как минимум стэк технологий шире
Ну не правда, со Spring можно обходиться без какого либо xml. Читайте про Java Configuration.
Хотя я по старинке методом копирования завожу четыре XML файла — context, servlet, web и pom. Это простые и короткие файлы, содержимое которых от проекта к проекту не меняется. Кроме pom, в котором надо описывать содержимое проекта. Но он тоже прост как пять копеек.
А весь серьезный бутстрап приложения происходит так раз через Java Configuration.
В чем вы нашли сложность — ума не приложу.
Хотя я по старинке методом копирования завожу четыре XML файла — context, servlet, web и pom. Это простые и короткие файлы, содержимое которых от проекта к проекту не меняется. Кроме pom, в котором надо описывать содержимое проекта. Но он тоже прост как пять копеек.
А весь серьезный бутстрап приложения происходит так раз через Java Configuration.
В чем вы нашли сложность — ума не приложу.
А в чем собственно проблема? И как бы вы хотели чтобы выглядел роутинг?
Примерно вот так
guides.rubyonrails.org/routing.html
guides.rubyonrails.org/routing.html
shaelf, OnYourLips (коммент), Davert (коммент), взгляните на evan.pro/zf2-router-talk.html#slide1
Добавлять роуты разными способами, в т.ч. и через обращение к классам, можно было и в первом зенде.
Добавлять роуты разными способами, в т.ч. и через обращение к классам, можно было и в первом зенде.
Не увидел каких либо объективных преимуществ. Не приведете пример в коде с пояснениями, в чем именно преимущество?
Никогда не приведут:-)
Просто многие ребята думают, что рельсы(а также весь хлам «вдохновленный» ими), априори круто, потому что не пробовали писать по-другому. Надеюсь никто не обидится, но реально есть 100500 других способов построить приложение, с другими паттернами, другой идеологией.
Надо чтоли написать рельсы на ZF 2, чтобы все наконец поняли, что рельсы это очень ограниченный фреймворк и бездумно следовать его гайдам — идиотизм!
P.S. Писал на RoR, Grails и прекрасно представляю о чем говорю. Сейчас пишу для себя только на ZF.
Просто многие ребята думают, что рельсы(а также весь хлам «вдохновленный» ими), априори круто, потому что не пробовали писать по-другому. Надеюсь никто не обидится, но реально есть 100500 других способов построить приложение, с другими паттернами, другой идеологией.
Надо чтоли написать рельсы на ZF 2, чтобы все наконец поняли, что рельсы это очень ограниченный фреймворк и бездумно следовать его гайдам — идиотизм!
P.S. Писал на RoR, Grails и прекрасно представляю о чем говорю. Сейчас пишу для себя только на ZF.
Либо плохо писали на RoR, либо совершенно не поняли ни предназначения RoR, ни их концепции. При этом я не говорю, что RoR априори крут. Но назвать его хуже ZF, как минимум первого — это уже походит на абсолютную слепоту.
Выводы из личных наблюдений, когда в компании опытных разработчиков на ZF и Yii сажали на RoR проекты, чтобы они учились, и в итоге они признают — что RoR удобнее во многом, как минимум в том, что для ежедневных задач уже есть готовое решение.
P. S. Ушел на Rails с Django, который ничем не хуже ZF.
Выводы из личных наблюдений, когда в компании опытных разработчиков на ZF и Yii сажали на RoR проекты, чтобы они учились, и в итоге они признают — что RoR удобнее во многом, как минимум в том, что для ежедневных задач уже есть готовое решение.
P. S. Ушел на Rails с Django, который ничем не хуже ZF.
Ну вот одно из преимуществ — весь приведенный ваше код
в рельсах задается одной строчкой:
Всё! Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений, то скорее всего вам платят за кол-во строчек кода.
в рельсах задается одной строчкой:
resources :albums
Всё! Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений, то скорее всего вам платят за кол-во строчек кода.
Это не преимущество, это всего лишь форма записи маршрута. Возможнао она удобна для вас (возможно даже для многих рубистов), но объективно она не лучше и не хуже зендовской.
В зенде вы точно так же можете написать свой тип маршрута (скорее всего просто расширив уже имеющийся segment), определить для него свой тип записи и набор правил и потом пользоваться так же:
Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
А вообще, мне кажется, вы не поняли идеологию зенда. Зенд не предоствляет готовых решений чтобы сделать блог за 15 минут. Зенд предоствляет хорошо спроектированные и легко расширяемые решения типовых задач.
При этом не пытается решить проблемы специфичные для какого-то конкретного проекта или удовлетворить вкус конкретного программиста, вместо этого он даёт инструменты для легкого изменения любой части фреймворка под свой вкус.
В зенде вы точно так же можете написать свой тип маршрута (скорее всего просто расширив уже имеющийся segment), определить для него свой тип записи и набор правил и потом пользоваться так же:
'albums' => ['type' => 'resource'] или 'items' => ['type' => 'resource']Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
А вообще, мне кажется, вы не поняли идеологию зенда. Зенд не предоствляет готовых решений чтобы сделать блог за 15 минут. Зенд предоствляет хорошо спроектированные и легко расширяемые решения типовых задач.
При этом не пытается решить проблемы специфичные для какого-то конкретного проекта или удовлетворить вкус конкретного программиста, вместо этого он даёт инструменты для легкого изменения любой части фреймворка под свой вкус.
А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем сколько стоит «В зенде вы точно так же можете написать свой тип маршрута». Вам не кажется что, это такой древний русский подход, предусматривающий фазу тщательной обработки напильником?
Мнение основано на личных стереотипах.
Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
Мнение основано на личных стереотипах.
Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
>>>А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем
>>>сколько стоит «В зенде вы точно так же можете написать свой тип маршрута».
Посчитали? Что получилось? 2.5$? Круто, осталось учесть, что врядли кто-то действительно потратит на него своё время — он просто никому не нужен, кроме фанатов РоР. Но фанаты и так уже пишут на рельсах.
>>>Вам не кажется что, это такой древний русский подход,
>>>предусматривающий фазу тщательной обработки напильником?
Не кажется. Зенд даёт инструменты, а не готовые решения.
А вообще если так рассуждать — то почему вы пишете на РоР, а не на каком-нибудь друпале или ворпрессе? Там же ещё меньше делать надо.
>>>Мнение основано на личных стереотипах.
Мнение основано на личном опыте, опыте коллег а так же по листу рассылки ZF — там тоже никто никогда, на моей памяти, не предлагал включить копию какого-то маршрута из РоР. Видимо он всё таки никому не нужен.
>>>Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Смотрел. Чем лучше? Почему вы постоянно делаете голословные утверждения?
>>>сколько стоит «В зенде вы точно так же можете написать свой тип маршрута».
Посчитали? Что получилось? 2.5$? Круто, осталось учесть, что врядли кто-то действительно потратит на него своё время — он просто никому не нужен, кроме фанатов РоР. Но фанаты и так уже пишут на рельсах.
>>>Вам не кажется что, это такой древний русский подход,
>>>предусматривающий фазу тщательной обработки напильником?
Не кажется. Зенд даёт инструменты, а не готовые решения.
А вообще если так рассуждать — то почему вы пишете на РоР, а не на каком-нибудь друпале или ворпрессе? Там же ещё меньше делать надо.
>>>Мнение основано на личных стереотипах.
Мнение основано на личном опыте, опыте коллег а так же по листу рассылки ZF — там тоже никто никогда, на моей памяти, не предлагал включить копию какого-то маршрута из РоР. Видимо он всё таки никому не нужен.
>>>Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Смотрел. Чем лучше? Почему вы постоянно делаете голословные утверждения?
Ну и по поводу этого:
>>>Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений,
>>>то скорее всего вам платят за кол-во строчек кода.
Не стоит переходить на личности — я сейчас тоже могу предположить что вы просто не осилили роутер зенда и вам проще, когда дают готовый набор правил, как в РоРе и не надо думать своей головой. Но после этого диалог, скорее всего, кончится и начнётся срач.
Так что давайте не будем переходить на личности и попытаемся просто разобрать плюсы и минусы разных подходов, ок?
>>>Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений,
>>>то скорее всего вам платят за кол-во строчек кода.
Не стоит переходить на личности — я сейчас тоже могу предположить что вы просто не осилили роутер зенда и вам проще, когда дают готовый набор правил, как в РоРе и не надо думать своей головой. Но после этого диалог, скорее всего, кончится и начнётся срач.
Так что давайте не будем переходить на личности и попытаемся просто разобрать плюсы и минусы разных подходов, ок?
Ну я не обращался лично к вам. Многим людям понравится зендовский роутинг.
Но решая рутинные задачи вроде писать массив и вставлять туда регексовые значения в нужные скобочки, я не вижу никаких творческих или интеллектуальных задач. Роутер Зенда из средины 2000-ых. Осиливать там нечего, скорее нужно вспоминать.
Если про плюсы-минусы в Зенде.
— поддержка кода. Когда в проекте 100 роутов, то задавая каждый таким массивом вы закопаетесь. Будет легко что-то сломать, сложно добавить, сложно найти и исправить.
— избыточность данных с тем же регексом.
— слабая защищенность от ошибок в рантайме (IDE не подскажет, что тот или иной конфиг-ключ написан не так)
— кол-во кода которое нужно написать для решения элементарной задачи.
Чем больше кода, тем сложнее его поддерживать, развивать, читать. Это для меня главное правило.
В рельсах есть как и прикольные шорткаты в виде ресурсов, так и возможности по кастомизации. Проблема Зенда в том, что предоставляя все наборы кастомизации можно было предложить и пару типичных решений типичных проблем. Имхо за тем и нужны фреймворки. Чтобы решать типичные проблемы.
Но решая рутинные задачи вроде писать массив и вставлять туда регексовые значения в нужные скобочки, я не вижу никаких творческих или интеллектуальных задач. Роутер Зенда из средины 2000-ых. Осиливать там нечего, скорее нужно вспоминать.
Если про плюсы-минусы в Зенде.
— поддержка кода. Когда в проекте 100 роутов, то задавая каждый таким массивом вы закопаетесь. Будет легко что-то сломать, сложно добавить, сложно найти и исправить.
— избыточность данных с тем же регексом.
— слабая защищенность от ошибок в рантайме (IDE не подскажет, что тот или иной конфиг-ключ написан не так)
— кол-во кода которое нужно написать для решения элементарной задачи.
Чем больше кода, тем сложнее его поддерживать, развивать, читать. Это для меня главное правило.
В рельсах есть как и прикольные шорткаты в виде ресурсов, так и возможности по кастомизации. Проблема Зенда в том, что предоставляя все наборы кастомизации можно было предложить и пару типичных решений типичных проблем. Имхо за тем и нужны фреймворки. Чтобы решать типичные проблемы.
Вы посмотрите в примере на framework.zend.com/manual/2.0/en/user-guide/database-and-models.html и framework.zend.com/manual/2.0/en/user-guide/forms-and-actions.html
Это зомби-монстр из начала 2000-х, когда мы говорим enterprise и подразумеваемdevelopers, developers, developers десятки тысяч строк кода что бы сделать базовые вещи. Все уже давно переболели этой болезнью (весь ентерпрайз с java и стеком мс), когда один продукт должен был уметь делать все и сразу, а количество конфигурационных файлов на xml по объему было близко к количеству всего кода в продукте.
Это зомби-монстр из начала 2000-х, когда мы говорим enterprise и подразумеваем
Приведите пожалуйста примеры адекватного роутинга, как раз думаю над его модернизацией, ищу, где почерпнуть идеи;)
Что-нибудь вроде
article_show:
pattern: /articles/{culture}/{year}/{title}.{_format}
defaults: { _controller: AcmeDemoBundle:Article:show, _format: html }
requirements:
culture: en|fr
_format: html|rss
year: \d+
кстати, да. в sf2 вполне себе красиво реализовано описание роутов. даже если и в php-варианте.
Угу, тот же маршрут на PHP:
А если забить на 5.3, то ещё лаконичнее будет.
$routes->add('homepage', new Route('/articles/{culture}/{year}/{title}.{_format}', array(
'_controller' => 'AcmeDemoBundle:Article:show',
'_format' => 'html',
), array(
'culture' => 'en|fr',
'_format' => 'html|rss',
'year' => '\d+',
)));
А если забить на 5.3, то ещё лаконичнее будет.
А как для вас выглядит идеальный роутинг и где (пусть не он, но близкий к идеалу) реализован?
Вот так выглядит лаконичный файл с роутингом для модуля новости:
from django.conf.urls.defaults import *
urlpatterns = patterns('news.views',
url(r'^$', 'news_index'),
url(r'^(?P<section>[\w-]+)/$', 'news_section'),
url(r'^(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/(?P<slug>[\w-]+)/$', 'news_one'),
)
а людям как это парсить? 0.о
Ну не всем людям — только програмистам ;-) Обычные регулярные выражения — в массе своей для url как раз 3-5 вариантов хватает — запоминается легко. Ведь вы сами сможете ответить, какому шаблону соответствет строка
/2012/08/29/hello-school/Да. но просто читабельность теряется. Да и как говорится: если вы решаете проблему с помощью регулярных выражений, то у вас уже две проблемы ) Но вцелом, на вкус и цвет…
Даже начинающий кодер поймёт, что значит
|^/[0-9]{4}/[0-9]{2}/[0-9]{2}/[a-z\-]+/$|, а вот чтобы понять роутинг ZF2, нужно правда быть героем, кроме того регулярные выражения — это стандартное средство языка, понял его один раз и используешь. По поводу двух проблем — не обращайте внимание, кто-то ляпнул сгоряча и сообщество вдруг восприняло это как догму, регулярки изначально были сделаны для обработки текста — и они справляются с этим отлично.Даже начинающий кодер поймёт, что значит
|^/[0-9]{4}/[0-9]{2}/[0-9]{2}/[a-z\-]+/$|, а вот чтобы понять роутинг ZF2, нужно правда быть героем, кроме того регулярные выражения — это стандартное средство языка, понял его один раз и используешь. По поводу двух проблем — не обращайте внимание, кто-то ляпнул сгоряча и сообщество вдруг восприняло это как догму, регулярки изначально были сделаны для обработки текста — и они справляются с этим отлично.посмотрите роутинг в rails guides.rubyonrails.org/routing.html он чертовски хорош, особенно если мы говорим про REST роутинг.
вот как это может выглядеть:
resources :users do
resources :comments
end
вот как это может выглядеть:
resources :users do
resources :comments
end
На зенде это реализуется очень просто — habrahabr.ru/post/150984/#comment_5120061
Но зачем? Это частное решение написание которого занимает 3 минуты рабочего времени. Зачем его пихать в основную поставку фреймворка?
Но зачем? Это частное решение написание которого занимает 3 минуты рабочего времени. Зачем его пихать в основную поставку фреймворка?
habrahabr.ru/post/112966/ тут я подробно об этом писал с примерами кода «было» «стало».
«Зачем его пихать в основную поставку фреймворка?» эта штука намного более ключевая чем тот же пейджинг, которого, кстати, в рельсах нет, в отличие от zend. Но в целом это вопрос уровня не кода, а идеологии и влияния.
«Зачем его пихать в основную поставку фреймворка?» эта штука намного более ключевая чем тот же пейджинг, которого, кстати, в рельсах нет, в отличие от zend. Но в целом это вопрос уровня не кода, а идеологии и влияния.
Это не ключевая штука, это частный случай маршрутизации. Он, видимо, очень удобен для фанатов РоР, но от этого он не перестаёт быть маленьким частным случаем. К тому же на зенде он воспроизовдиться за несколько минут.
Почему вы его называется «ключевым»?
Зенд не даёт готовых красивых маршрутов. Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.
Пост прочитаю, спасибо.
Почему вы его называется «ключевым»?
Зенд не даёт готовых красивых маршрутов. Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.
Пост прочитаю, спасибо.
Ключевая потому что большинство рейлс приложений представляют собой рест приложение, что позволяет проще на порядке делать api и пользоваться им. Вы посмотрите что из себя представляет любое зенд приложение, это кучи именованных маршрутов и почти никакой логики в их построении. В рельсах существуют десятки гемов которые дают вам множество автоматизированных рабочих инструментов (например acl) которые работают без конфигурироания и ручного написания кода при условии что вы используете rest (а используая такой роутинг рест сам собой появляется). И что бы вы там не говорили это не три минуты, каждый ресурс это сем маршрутов, вложенные маршруты и сгенерированные методы хелперы. И такая автоматизация касается абсолютно каждого аспекта системы.
Вообще вот из чего все проистекает: Convention over configuration, и это больше чем сахар.
Вообще вот из чего все проистекает: Convention over configuration, и это больше чем сахар.
Я смотрю на зенд приложения каждый день. Не первом зенде многие приложения вообще обходятся одним маршрутом по умолчанию.
Вопрос логики в построении маршрутов — это вопрос программиста, который проектирует приложение, но никак не фреймворка.
Вы не поняли, на что надо потратить 3.
Их надо потратить не на то, чтобы написать 7 маршрутов для одного ресурса, а на то, чтобы написать один класс наслединк Zend\Mvc\Router\Http\Segment, назвать его «Resource» и потом пользоваться им так же, как вы пользуетесь в РоР:
Всё. Этот код включает в себя 7 маршрутов и вложенные маршруты при надобности. И его можно использовать для маршрутизации по любым ресурсам.
Ещё раз — это частное решение почему-то очень полюбившееся разработчиком на рельсах. Вообще не понимаю, почему оно столько раз упоминается в этой теме.
Вопрос логики в построении маршрутов — это вопрос программиста, который проектирует приложение, но никак не фреймворка.
Вы не поняли, на что надо потратить 3.
Их надо потратить не на то, чтобы написать 7 маршрутов для одного ресурса, а на то, чтобы написать один класс наслединк Zend\Mvc\Router\Http\Segment, назвать его «Resource» и потом пользоваться им так же, как вы пользуетесь в РоР:
'albums' => ['type' => 'resource']Всё. Этот код включает в себя 7 маршрутов и вложенные маршруты при надобности. И его можно использовать для маршрутизации по любым ресурсам.
Ещё раз — это частное решение почему-то очень полюбившееся разработчиком на рельсах. Вообще не понимаю, почему оно столько раз упоминается в этой теме.
«Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.»
да понятно откуда это идет, еще метью давно говорил о том что для него идеальный фреймворк и он видит как люди делают компоненты и повторно их используют. Только пока это все еще мечта, а в рельсах тысяч компонент на все случаи жизни которые используются годами.
Вы же знаете что зенд начинался как набор библиотек. Так вот почти все что есть в зенде, в других языках реализовано сторонними библиотеками которые все юзают. И это уже проблема php.
да понятно откуда это идет, еще метью давно говорил о том что для него идеальный фреймворк и он видит как люди делают компоненты и повторно их используют. Только пока это все еще мечта, а в рельсах тысяч компонент на все случаи жизни которые используются годами.
Вы же знаете что зенд начинался как набор библиотек. Так вот почти все что есть в зенде, в других языках реализовано сторонними библиотеками которые все юзают. И это уже проблема php.
По личному опыту, работая с конфигами этого DI ОЧЕНЬ ЧАСТО первое время путаешь уровень вложенности какого-то параметра, и потом долго и упорно «почему не работает как надо?». Отлаживать эти конфиги — да вообще никак.
Старый подход с бутстраппингом мне больше нравился.
Старый подход с бутстраппингом мне больше нравился.
Ох йой… А я думал, что он года два назад уже вышел (сам на пхп уже года 4 не пишу).
Хм, поясню свою мысль.
Возьмём, например, конференцию 2010 года: zfconf.org.ua/conf-2010/category/topics/ первый доклад «Встречайте Zend Framework 2.0».
Примерно с тех пор я перестал встречать ZF1, но зато о ZF2 писали везде.
Возьмём, например, конференцию 2010 года: zfconf.org.ua/conf-2010/category/topics/ первый доклад «Встречайте Zend Framework 2.0».
Примерно с тех пор я перестал встречать ZF1, но зато о ZF2 писали везде.
Отличная новость. Как раз начинаем новый проект и были колебания с ZF1, теперь будем на ZF2 создавать новую систему. Вовремя.
тоже об этом думал. Но, как то, примерчики из тутора отбивают любое желание с этим возиться
Попробуйте Symfony 2.1 :) вот-вот будет релиз, но RC2 уже стабилен и хорош )
Тоже сегодня релизнулись: symfony.com/blog/symfony-2-1-0-released
Попробуйте ещё Yii 1.1.12. Отличный баланс функциональности и «тяжёлости»/легковесности.
Единственное, почему не использую пока, это то что нет zend tool консольной как в 1ом. Хотелось бы scaffold иметь как в ROR
Некоторые вещи в ZF1 мне казались реально неуклюжими, о чем я уже писал.
Посмотрим, может в ZF2 все эти недостатки уже устранены.
Посмотрим, может в ZF2 все эти недостатки уже устранены.
В честь выхода сломали все ссылки из гугла на документацию по первой версии.
Не является ли зелёный слоник на логотипе своеобразной аллегорией, отражающей недавние критические посты о PHP?
Наконец-то вышел из беты!
Встречайте по-настоящему reusable модули и полноценный MVVM!
Работать будет только с 5.4, так что все желающие потестить, обновитесь!
Встречайте по-настоящему reusable модули и полноценный MVVM!
Работать будет только с 5.4, так что все желающие потестить, обновитесь!
А еще довольно низкая манипуляция от Zend.
Сами же пишут о том, что ZF2 совершенно новый FW, и ТУТ ЖЕ «most popular». Когда он успел самым популярным стать, если не вышел еще?
Огромное количество вложение в array конфигах — раздражает. Новая архитектура форм… пока не очень. непривычно наверное.
Производительность — радует. Разделение модулей по группам — тоже. Возможность установки модулей как плагинов (и вообще система этих новых плагинов) — вроде все правильно сделали.
В общем… смешанные впечатления. ZF1 был хорош тем что его можно было доработать под себя как захочешь. Так что самая главная проверка должна быть практикой, на это у меня пока времени нет. Будем наблюдать.
Сами же пишут о том, что ZF2 совершенно новый FW, и ТУТ ЖЕ «most popular». Когда он успел самым популярным стать, если не вышел еще?
Огромное количество вложение в array конфигах — раздражает. Новая архитектура форм… пока не очень. непривычно наверное.
Производительность — радует. Разделение модулей по группам — тоже. Возможность установки модулей как плагинов (и вообще система этих новых плагинов) — вроде все правильно сделали.
В общем… смешанные впечатления. ZF1 был хорош тем что его можно было доработать под себя как захочешь. Так что самая главная проверка должна быть практикой, на это у меня пока времени нет. Будем наблюдать.
Огромное количество вложений в массивах конфигах — сейчас есть только в роутере и только если у вас древовидная структура.
Новая архитектура форм — слегка непривычна в начале, но удобней чем старая. Преимущества раскрываются на больших формах и на большом количестве маленьких форм с пересекающимеся полями (можно написать один филдсет а потом просто включать нужные поля).
Гибкость ZF2 не только сохранил, но и улучшил — благодаря событиям и сервис менеждеру менять можно вообще что угодно (раньше MVC часть, например, расширялась не очень удобно)
В общем если вам нравиться ZF1 — почти наверняка понравитсья и ZF2.
Новая архитектура форм — слегка непривычна в начале, но удобней чем старая. Преимущества раскрываются на больших формах и на большом количестве маленьких форм с пересекающимеся полями (можно написать один филдсет а потом просто включать нужные поля).
Гибкость ZF2 не только сохранил, но и улучшил — благодаря событиям и сервис менеждеру менять можно вообще что угодно (раньше MVC часть, например, расширялась не очень удобно)
В общем если вам нравиться ZF1 — почти наверняка понравитсья и ZF2.
off: Тся, тся, будьте добры… и здесь и выше… да что ж такое…
насчет форм: я так понял, из того что я видел, так и нельзя создавать массив из вложенных форм и на него валидаторы навешивать? в динамических формах это часто используется. а когда вложений 2-3…
пример: большая форма заказа тура в отеле. можно заказать за раз сразу несколько номеров, в одном отеле, для разных людей. кроме этого, выбрать несколько опций. да еще для разных людей… в общем это жесть.
насчет форм: я так понял, из того что я видел, так и нельзя создавать массив из вложенных форм и на него валидаторы навешивать? в динамических формах это часто используется. а когда вложений 2-3…
пример: большая форма заказа тура в отеле. можно заказать за раз сразу несколько номеров, в одном отеле, для разных людей. кроме этого, выбрать несколько опций. да еще для разных людей… в общем это жесть.
Пожалуйсте, люди добрые, подскажите, где можно почерпнуть подробную информацию по роутингу в zf2, а лучше выложите php-array-like пример дефолтного роута zf1.
1) взять skeleton application
2) module/application/config/module.config
3) смотрим роут для application
4) child_routes=>default вроде то что нужно для вас. можно его перенести в корень тада будет такое же поведение.
2) module/application/config/module.config
3) смотрим роут для application
4) child_routes=>default вроде то что нужно для вас. можно его перенести в корень тада будет такое же поведение.
Попробовал:
результирует в 404 в корне (URI = /)
'router' => array(
'routes' => array(
'default' => array(
'type' => 'Segment',
'options' => array(
'route' => '/[:controller[/:action]]',
'constraints' => array(
'controller' => '[a-zA-Z][a-zA-Z0-9_-]*',
'action' => '[a-zA-Z][a-zA-Z0-9_-]*',
),
'defaults' => array(
'__NAMESPACE_' => 'Frontend\Controller',
'controller' => 'index',
'action' => 'index',
),
),
),
),
),
результирует в 404 в корне (URI = /)
Упс, пропустил "_" в неймспейсе.
Тем не менее.
/ — OK
/index/ — No RouteMatch instance provided
/index/index/ — соответственно, No RouteMatch instance provided
Тем не менее.
/ — OK
/index/ — No RouteMatch instance provided
/index/index/ — соответственно, No RouteMatch instance provided
Простите, нет под рукой в офисе пхп, (я ушел из веб-дева уже), как дома буду, проверю код. Возможно (а вернее точно) я ошибся, просто надо понять в чём.
'controller' => 'index'
Имя контроллера с верхнего регистра
Пробовал и с ведущей буквой.
Проблема оказалась совершенно в другом:
RouteMatcher в ZF2 не ловит пути, заканчивающиеся следующим бэкслэшем
Тоесть
Выкладываю свой роут, вдруг помогу кому:
Распознает пути типа:
Проблема оказалась совершенно в другом:
RouteMatcher в ZF2 не ловит пути, заканчивающиеся следующим бэкслэшем
/ Тоесть
/en/index/ — не валиден, а вот /en/index вполне катит/en/index/index/-> /en/index/index по аналогии.Выкладываю свой роут, вдруг помогу кому:
'router' => array(
'routes' => array(
'root' => array(
'type' => 'literal',
'options' => array(
'route' => '/',
'defaults' => array(
'__NAMESPACE__' => 'Shop\Controller',
'controller' => 'Index',
'action' => 'index',
'lang' => 'en',
),
),
'may_terminate' => true,
'child_routes' => array(
'control' => array(
'type' => 'segment',
'options' => array(
'route' => '[:lang[/:controller[/:action]]][.html]',
'constraints' => array(
'lang' => '[a-z]{2}',
'controller' => '[a-zA-Z][a-zA-Z0-9_-]*',
'action' => '[a-zA-Z][a-zA-Z0-9_-]*',
),
'defaults' => array(
'controller' => 'Index',
'action' => 'index',
'lang' => 'en',
'module' => 'shop',
),
),
'may_terminate' => true,
'child_routes' => array(
'params' => array(
'type' => 'Wildcard',
'options' => array(
),
),
),
),
),
),
),
),
Распознает пути типа:
/en/controller/action либо/en/controller/action/param/value либо/en/controller/action.html либо/en/controller/action.html/param/valueЯ не понимаю, что они сделали.
Извините, но это быдло код.
Такая же фигня с модулями, я должен положить в корень модуля файл с классом Module, который не реализует ни интерфейс, ни абстрактный класс, откуда я должен знать почему Module и какие методы он должен иметь?
В пресс-релизах пишут, что ZF2 стал по настоящему объектно-ориентированным, но похоже, те кто это заявляет, не знают о чём говорят. ООП это не просто набор классов, это ещё (обязательно) и контрактное программирование, которое подразумевает интерфейсы, абстрактные классы и контроль типов.
Когда через несколько лет разработки, вендор языка предлагает это в качестве каркаса приложений, мне становится грустно. Zend, what are you doing?
Zend\Mvc\Application::init(include 'config/application.config.php')->run();
// config/application.config.php
return array(
'modules' => array(
'Application',
),
'module_listener_options' => array(
'config_glob_paths' => array(
'config/autoload/{,*.}{global,local}.php', // это на каком языке ? почему не pcre ?
),
'module_paths' => array(
'./module',
'./vendor',
),
),
);
Извините, но это быдло код.
Такая же фигня с модулями, я должен положить в корень модуля файл с классом Module, который не реализует ни интерфейс, ни абстрактный класс, откуда я должен знать почему Module и какие методы он должен иметь?
В пресс-релизах пишут, что ZF2 стал по настоящему объектно-ориентированным, но похоже, те кто это заявляет, не знают о чём говорят. ООП это не просто набор классов, это ещё (обязательно) и контрактное программирование, которое подразумевает интерфейсы, абстрактные классы и контроль типов.
Когда через несколько лет разработки, вендор языка предлагает это в качестве каркаса приложений, мне становится грустно. Zend, what are you doing?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел в свет Zend Framework 2 stable