Pull to refresh

Comments 115

То есть они там настолько все намудрили, что один факт работы с Зендом делает тебя героем.
Ок.
А судя по первой картинке, ZF2, видимо, должен ассоциироваться с неуклюжим зелёным слоником :-D
фиолетовый — лучше
Сколько себя помню, это же говорили и про всю первую ветку.
Честно говоря, большой опыт работы с первым зендом оказался у меня бессилен перед новой структурой MVC во втором. Ребята круты конечно, но назвать теперь фреймворк easy & intutive теперь нельзя.
Так и первый не был. Я сейчас в нем более-менее ориентируюсь — да, действительно, крутая штука. Но пока не пришло вот это понимание логики работы, парадигмы, что ли — просто кромешное болото какое-то.

Вроде того что вот есть у тебя форма и хочется тебе туда 1 сраный тэг добавить. А ты бьешься с декораторами полдня, пытаясь понять, почему когда 1 тэг добавляется, второй исчезает :-).

Со вторым, видимо, придется заново переживать этот адаптационный период беспросветного ужаса, чтобы потом наслаждаться легкостью и воздушностью :-).
насчет форм — да, одно из первых что пришлось сделать — добавить в проект PlainHtml декоторатор и фигачить туда прямой код… актуально когда надо посередине НУ ООЧЕНЬ типовой формы какой-то дизайнерский текст всобачить, и нехота для него элемент городить. но зато уже освоив Forms я уже влюбился в них) orm, scaffolding+беспросветная гибкость, до спуска вниз…
Наконец-то! Я уже даже перестал его ждать после второй беты.
Спасибо, исправил. Так торопился на радостях…
Ну все.
Ждем статей «ZF2 для начинающих», «Zend Framework 2: мнение начинающего разработчика» и тэ дэ
Что ж они так долго делали, что в 2012 году роутинг у них выглядит так?

    '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
омг. выкладывать примеры исходинков не моноширинным шрифтом — это порнография :)
На пару уровней сократить можно.
Но этот метаязык из нагромождения array выглядит уродливо, такое ощущение, что они не смотрели на другие фреймворки.
Замените php-array нотацию на json нотацию. Будет чуть менее уродливо.
Но все равно уродливо.

Почему они не осилили роуты в стиле new RouteResource('photos', new RouteSubject('member', 'preview', 'get'))?
А зачем делать массу лишних вызовов? Всё равно ведь внутренняя структура аналогична этой.
Где масса лишних вызовов?
ресурс = view + list + edit + update + new + create + delete с параметрами для них по умолчанию

Вам удобнее описывать каждый из этих суброутов в отдельности? Вы в ZF2 участие не принимали? :)
>>>ресурс = view + list + edit + update + new + create + delete с параметрами для них по умолчанию

Почему все рубисты в этом посте жалуются на то, что роутер зенда — это не роутер РоР? Да, он действительно другой, но почему это считается за минус?

И да, не обязательно описывать каждый суброут по отдельности, достаточно написать один раз и пользоваться для любого ресурса — habrahabr.ru/post/150984/#comment_5120061
Но этот маршрут нужен только любителям РоР, так что его нет в дефолтной поставке.
К хорошему быстро привыкаешь). Вот это gist.github.com/3673818 почти во всех фреймворках будет в пять раз длиннее и непонятнее, а еще никаким рест пахнуть даже отдаленно не будет. Руби силен своими dsl и здесь очень высоко ценится автоматизация. При этом среди разработчиков которые не использовали рельсы бытует мнение что «раз там все вот так, значит он трудно кастомизириуется и подходит только для ограниченного круга задач». Что является абсолютным заблуждением.

Не буду ни о чем спорить и прекрасно понимаю что все тоже самое можно в том или ином виде реализовать и в зенде (с поправкой на то то php не ruby) и более того я это делал правда для выборок.
Хорошее это или плохое — это дело вкуса, но никак не объективных плюсов или минусов подхода. Мне, например, такой подход в принципе не нравится, так что то, что его нет в стандартной поставке — плюс. А те, кому он нужен, потратят 3 минуты своего времи и сами его реализуют.

Рельсы — набор хорошо скомпонованных и подогнаных друг к другу спорных решений. Если в целом ты не против этих решений (взять тот же ActiveRecord, например) — то рельсы дают много плюшек и сильно сокращают время разработки. Но если ты против какого-то из них — усилия на изменение будут гораздо выше, чем в том же зенде.

В общем рельсы решают частный случай какой-то проблемы, зенд — решает общий случай, а частности оставляет за программистом.
Если частный — это веб-разработка любого уровня сложности, то я согласен.
Да хоть yaml, который выглядит гораздо лаконичнее всего остального. Это ужасно. Это ужасно настолько, насколько это вообще может быть ужасно
Как бы вы хотели написать этот же маршрут? Можно пример в коде?
Это не пример в коде, это ссылка на документацию Play`a.

Не могли бы здесь привести пример кода сложного маршрута и рассказать о его преимуществах?
Конфиги «из коробки» можно вести в Ini-файлах, XML-е, YAML-е, JSON-е ну и как видите на чистом PHP (разумеется так работает быстрее).

Похожим образом описываются не только роуты, но другие настройки вашего проекта. К этому очень быстро привыкаешь. До недавнего времени была большая проблема с докой к компонентам и разобраться как правильно писать конфиги можно было только по рабочим примерам. Сейчас же я вижу нормальную доку.

Не пугайтесь, все намного проще чем кажется! :)
Не буду говорить как там устроены конфиги, но по идее, даже если они в YAML, то при первом обращении скрипта к конфигам, они должны ложится в виде PHP массива в кэш и повторно читаться уже из кэша в готовом виде без преобразования. Это как пример. На производительность влиять не должно.
Кешировать сам зенд не будет, нужна обертка.
Ведение настроек в YAML тормозили проект раз в 10. Я честно тогда был в ступоре, как же хреново нужно написать парсер yaml…
Однажды на хабре уже развенчали миф про то, что конфиг на чистом php быстрее habrahabr.ru/post/112402/. Ini-файлы и JSON быстрее массивов на PHP.
Прошу заметить, что стандартный парсинг ini-файлов предполагает максимальную вложенность массива 2го уровня, т.е. [секция] [ключ]=[значение] нежели стандартный массив
ключ.третьего.уровня = значение
Ради интереса — посмотрите сэмпловый пример обычного 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 (во многих случаях даже наоборот), но как минимум стэк технологий шире

Ну не правда, со Spring можно обходиться без какого либо xml. Читайте про Java Configuration.

Хотя я по старинке методом копирования завожу четыре XML файла — context, servlet, web и pom. Это простые и короткие файлы, содержимое которых от проекта к проекту не меняется. Кроме pom, в котором надо описывать содержимое проекта. Но он тоже прост как пять копеек.

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

В чем вы нашли сложность — ума не приложу.

А в чем собственно проблема? И как бы вы хотели чтобы выглядел роутинг?
Ага, добавлять можно, но по скорости всё равно лучше делать все в массивых. Или как-то настраивать кеширование.
Суть в том, что по дефолту, всё это сложно, и необходимо допиливать, как в старом анекдоте.
Не увидел каких либо объективных преимуществ. Не приведете пример в коде с пояснениями, в чем именно преимущество?
Никогда не приведут:-)

Просто многие ребята думают, что рельсы(а также весь хлам «вдохновленный» ими), априори круто, потому что не пробовали писать по-другому. Надеюсь никто не обидится, но реально есть 100500 других способов построить приложение, с другими паттернами, другой идеологией.

Надо чтоли написать рельсы на ZF 2, чтобы все наконец поняли, что рельсы это очень ограниченный фреймворк и бездумно следовать его гайдам — идиотизм!

P.S. Писал на RoR, Grails и прекрасно представляю о чем говорю. Сейчас пишу для себя только на ZF.
Либо плохо писали на RoR, либо совершенно не поняли ни предназначения RoR, ни их концепции. При этом я не говорю, что RoR априори крут. Но назвать его хуже ZF, как минимум первого — это уже походит на абсолютную слепоту.

Выводы из личных наблюдений, когда в компании опытных разработчиков на ZF и Yii сажали на RoR проекты, чтобы они учились, и в итоге они признают — что RoR удобнее во многом, как минимум в том, что для ежедневных задач уже есть готовое решение.

P. S. Ушел на Rails с Django, который ничем не хуже ZF.
По теме: не вижу ничего плохого в том, чтобы в Zend сделали бы хотя бы попытку к внедрению мини DSL для роутинга, хоть бы даже ispired RoR. Думается, это бы выглядело чуть более нагляднее, чем массивы, IMHO.
Не знаю как Zend, но некоторые другие PHP-фреймворки позволяют описывать роутинг (и прочие конфиги) в нескольких (PHP, Ini, XML, YAML) из коробки, плюс прикручивать свои парсеры для произвольного формата.
Ну вот одно из преимуществ — весь приведенный ваше код
в рельсах задается одной строчкой:

resources :albums


Всё! Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений, то скорее всего вам платят за кол-во строчек кода.
Это не преимущество, это всего лишь форма записи маршрута. Возможнао она удобна для вас (возможно даже для многих рубистов), но объективно она не лучше и не хуже зендовской.

В зенде вы точно так же можете написать свой тип маршрута (скорее всего просто расширив уже имеющийся segment), определить для него свой тип записи и набор правил и потом пользоваться так же:

'albums' => ['type' => 'resource'] или 'items' => ['type' => 'resource']

Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).

А вообще, мне кажется, вы не поняли идеологию зенда. Зенд не предоствляет готовых решений чтобы сделать блог за 15 минут. Зенд предоствляет хорошо спроектированные и легко расширяемые решения типовых задач.
При этом не пытается решить проблемы специфичные для какого-то конкретного проекта или удовлетворить вкус конкретного программиста, вместо этого он даёт инструменты для легкого изменения любой части фреймворка под свой вкус.

А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем сколько стоит «В зенде вы точно так же можете написать свой тип маршрута». Вам не кажется что, это такой древний русский подход, предусматривающий фазу тщательной обработки напильником?

Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).

Мнение основано на личных стереотипах.
Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.

>>>А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем
>>>сколько стоит «В зенде вы точно так же можете написать свой тип маршрута».

Посчитали? Что получилось? 2.5$? Круто, осталось учесть, что врядли кто-то действительно потратит на него своё время — он просто никому не нужен, кроме фанатов РоР. Но фанаты и так уже пишут на рельсах.

>>>Вам не кажется что, это такой древний русский подход,
>>>предусматривающий фазу тщательной обработки напильником?

Не кажется. Зенд даёт инструменты, а не готовые решения.
А вообще если так рассуждать — то почему вы пишете на РоР, а не на каком-нибудь друпале или ворпрессе? Там же ещё меньше делать надо.

>>>Мнение основано на личных стереотипах.

Мнение основано на личном опыте, опыте коллег а так же по листу рассылки ZF — там тоже никто никогда, на моей памяти, не предлагал включить копию какого-то маршрута из РоР. Видимо он всё таки никому не нужен.

>>>Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.

Смотрел. Чем лучше? Почему вы постоянно делаете голословные утверждения?

Да-да, Зенд самый крутой и у него самый крутой роутинг. А тот кто так не считает — недальновидный фанат!!!
Ну и по поводу этого:
>>>Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений,
>>>то скорее всего вам платят за кол-во строчек кода.

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

Так что давайте не будем переходить на личности и попытаемся просто разобрать плюсы и минусы разных подходов, ок?
Ну я не обращался лично к вам. Многим людям понравится зендовский роутинг.
Но решая рутинные задачи вроде писать массив и вставлять туда регексовые значения в нужные скобочки, я не вижу никаких творческих или интеллектуальных задач. Роутер Зенда из средины 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 по объему было близко к количеству всего кода в продукте.
Приведите пожалуйста примеры адекватного роутинга, как раз думаю над его модернизацией, ищу, где почерпнуть идеи;)
Что-нибудь вроде
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:
$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
На зенде это реализуется очень просто — habrahabr.ru/post/150984/#comment_5120061

Но зачем? Это частное решение написание которого занимает 3 минуты рабочего времени. Зачем его пихать в основную поставку фреймворка?
habrahabr.ru/post/112966/ тут я подробно об этом писал с примерами кода «было» «стало».

«Зачем его пихать в основную поставку фреймворка?» эта штука намного более ключевая чем тот же пейджинг, которого, кстати, в рельсах нет, в отличие от zend. Но в целом это вопрос уровня не кода, а идеологии и влияния.
Это не ключевая штука, это частный случай маршрутизации. Он, видимо, очень удобен для фанатов РоР, но от этого он не перестаёт быть маленьким частным случаем. К тому же на зенде он воспроизовдиться за несколько минут.
Почему вы его называется «ключевым»?

Зенд не даёт готовых красивых маршрутов. Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.

Пост прочитаю, спасибо.
Ключевая потому что большинство рейлс приложений представляют собой рест приложение, что позволяет проще на порядке делать api и пользоваться им. Вы посмотрите что из себя представляет любое зенд приложение, это кучи именованных маршрутов и почти никакой логики в их построении. В рельсах существуют десятки гемов которые дают вам множество автоматизированных рабочих инструментов (например acl) которые работают без конфигурироания и ручного написания кода при условии что вы используете rest (а используая такой роутинг рест сам собой появляется). И что бы вы там не говорили это не три минуты, каждый ресурс это сем маршрутов, вложенные маршруты и сгенерированные методы хелперы. И такая автоматизация касается абсолютно каждого аспекта системы.

Вообще вот из чего все проистекает: Convention over configuration, и это больше чем сахар.
Я смотрю на зенд приложения каждый день. Не первом зенде многие приложения вообще обходятся одним маршрутом по умолчанию.
Вопрос логики в построении маршрутов — это вопрос программиста, который проектирует приложение, но никак не фреймворка.

Вы не поняли, на что надо потратить 3.
Их надо потратить не на то, чтобы написать 7 маршрутов для одного ресурса, а на то, чтобы написать один класс наслединк Zend\Mvc\Router\Http\Segment, назвать его «Resource» и потом пользоваться им так же, как вы пользуетесь в РоР:
'albums' => ['type' => 'resource']
Всё. Этот код включает в себя 7 маршрутов и вложенные маршруты при надобности. И его можно использовать для маршрутизации по любым ресурсам.

Ещё раз — это частное решение почему-то очень полюбившееся разработчиком на рельсах. Вообще не понимаю, почему оно столько раз упоминается в этой теме.
ок давайте тему развивать не будем, я просто хотел чтобы вы поняли позицию рейлс разработчиков, при этом что я был по обе стороны баррикад и понимаю вашу позицию, хотя и в корне с ней не согласен.
Ок, без проблем. Я понимаю позицию рельс разработчиков но мне совершенно не нравиться подход применямый в рельсах и уже тем более не нравиться, когда пытаются упрекнуть зенд в том, что он не рельсы.
«Зенд даёт иструменты для построения любой (абсолютно любой) маршрутизации, не отдавая при этом предпочтения какому-то конкретному способу.»

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

Вы же знаете что зенд начинался как набор библиотек. Так вот почти все что есть в зенде, в других языках реализовано сторонними библиотеками которые все юзают. И это уже проблема php.
По личному опыту, работая с конфигами этого DI ОЧЕНЬ ЧАСТО первое время путаешь уровень вложенности какого-то параметра, и потом долго и упорно «почему не работает как надо?». Отлаживать эти конфиги — да вообще никак.
Старый подход с бутстраппингом мне больше нравился.
DI в ZF2 практически не используется (вообще не встречал в коде начиная с beta3, кажется). Если вы не смотрели фрейморк со времен первых бет — советую посмотреть, там много чего изменилось в лучшую сторону.

хорошо, возможно Вы и правы, но последнее что ковырял beta4 была. надо будет еще раз пройтись по релизу.
Ох йой… А я думал, что он года два назад уже вышел (сам на пхп уже года 4 не пишу).
Хм, поясню свою мысль.
Возьмём, например, конференцию 2010 года: zfconf.org.ua/conf-2010/category/topics/ первый доклад «Встречайте Zend Framework 2.0».
Примерно с тех пор я перестал встречать ZF1, но зато о ZF2 писали везде.
Отличная новость. Как раз начинаем новый проект и были колебания с ZF1, теперь будем на ZF2 создавать новую систему. Вовремя.
тоже об этом думал. Но, как то, примерчики из тутора отбивают любое желание с этим возиться
Попробуйте Symfony 2.1 :) вот-вот будет релиз, но RC2 уже стабилен и хорош )
ага ) меньше часа обратно
На таких радостях пошёл изучать symfony
Попробуйте ещё Yii 1.1.12. Отличный баланс функциональности и «тяжёлости»/легковесности.
Единственное, почему не использую пока, это то что нет zend tool консольной как в 1ом. Хотелось бы scaffold иметь как в ROR
Некоторые вещи в ZF1 мне казались реально неуклюжими, о чем я уже писал.
Посмотрим, может в ZF2 все эти недостатки уже устранены.
В честь выхода сломали все ссылки из гугла на документацию по первой версии.
Не в первой уже, кстати.
Не является ли зелёный слоник на логотипе своеобразной аллегорией, отражающей недавние критические посты о PHP?
Наконец-то вышел из беты!
Встречайте по-настоящему reusable модули и полноценный MVVM!
Работать будет только с 5.4, так что все желающие потестить, обновитесь!

> Работать будет только с 5.4, так что все желающие потестить, обновитесь!

Откуда инфа?
в дереве исходников есть АЖ ОДИН (!) файл который требует 5.4. Опциональная поддержка событий через trait.
belki.jpg
    "require": {
        "zendframework/zend-config": "2.0.*",
        "zendframework/zend-http": "2.0.*",
        "php": ">=5.3.3"
    }

причем тут 5.4?
А еще довольно низкая манипуляция от Zend.
Сами же пишут о том, что ZF2 совершенно новый FW, и ТУТ ЖЕ «most popular». Когда он успел самым популярным стать, если не вышел еще?
Огромное количество вложение в array конфигах — раздражает. Новая архитектура форм… пока не очень. непривычно наверное.
Производительность — радует. Разделение модулей по группам — тоже. Возможность установки модулей как плагинов (и вообще система этих новых плагинов) — вроде все правильно сделали.
В общем… смешанные впечатления. ZF1 был хорош тем что его можно было доработать под себя как захочешь. Так что самая главная проверка должна быть практикой, на это у меня пока времени нет. Будем наблюдать.
Огромное количество вложений в массивах конфигах — сейчас есть только в роутере и только если у вас древовидная структура.
Новая архитектура форм — слегка непривычна в начале, но удобней чем старая. Преимущества раскрываются на больших формах и на большом количестве маленьких форм с пересекающимеся полями (можно написать один филдсет а потом просто включать нужные поля).

Гибкость ZF2 не только сохранил, но и улучшил — благодаря событиям и сервис менеждеру менять можно вообще что угодно (раньше MVC часть, например, расширялась не очень удобно)

В общем если вам нравиться ZF1 — почти наверняка понравитсья и ZF2.
off: Тся, тся, будьте добры… и здесь и выше… да что ж такое…

насчет форм: я так понял, из того что я видел, так и нельзя создавать массив из вложенных форм и на него валидаторы навешивать? в динамических формах это часто используется. а когда вложений 2-3…
пример: большая форма заказа тура в отеле. можно заказать за раз сразу несколько номеров, в одном отеле, для разных людей. кроме этого, выбрать несколько опций. да еще для разных людей… в общем это жесть.
Пожалуйсте, люди добрые, подскажите, где можно почерпнуть подробную информацию по роутингу в zf2, а лучше выложите php-array-like пример дефолтного роута zf1.
1) взять skeleton application
2) module/application/config/module.config
3) смотрим роут для application
4) child_routes=>default вроде то что нужно для вас. можно его перенести в корень тада будет такое же поведение.
Попробовал:
'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
Простите, нет под рукой в офисе пхп, (я ушел из веб-дева уже), как дома буду, проверю код. Возможно (а вернее точно) я ошибся, просто надо понять в чём.
Вот я второй день и не понимаю. Возможно тут какой-то сакральный смысл заложен.
БУдем ждать, пока форумы обрастут этой темой, или все же найдется магистр путей.
Оу… ладно, видать это я еще оптимист был в ветке выше. Все печально видимо) (давайте если что в личку дальше)
'controller' => 'index'

Имя контроллера с верхнего регистра
Пробовал и с ведущей буквой.
Проблема оказалась совершенно в другом:
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
Регулярку поменяй на такую:
'lang' => '[a-z]{2}?',
'controller' => '[a-zA-Z]?[a-zA-Z0-9_-]*',
'action' => '[a-zA-Z]?[a-zA-Z0-9_-]*',

и будет тебе счастье)
Я не понимаю, что они сделали.
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?
Согласен с каждой строчкой, похожее смешанное ощущение. ОООП. очень(без смысла) объекто-ориентированное программирование.
KISS по ним плачет.
Контроль типов там есть… но не там где нужно. мне бы лучше как раз в конфигурации все эти проверки были.
Only those users with full accounts are able to leave comments. Log in, please.