Согласен с каждой строчкой, похожее смешанное ощущение. ОООП. очень(без смысла) объекто-ориентированное программирование.
KISS по ним плачет.
Контроль типов там есть… но не там где нужно. мне бы лучше как раз в конфигурации все эти проверки были.
насчет форм — да, одно из первых что пришлось сделать — добавить в проект PlainHtml декоторатор и фигачить туда прямой код… актуально когда надо посередине НУ ООЧЕНЬ типовой формы какой-то дизайнерский текст всобачить, и нехота для него элемент городить. но зато уже освоив Forms я уже влюбился в них) orm, scaffolding+беспросветная гибкость, до спуска вниз…
Простите, нет под рукой в офисе пхп, (я ушел из веб-дева уже), как дома буду, проверю код. Возможно (а вернее точно) я ошибся, просто надо понять в чём.
1) взять skeleton application
2) module/application/config/module.config
3) смотрим роут для application
4) child_routes=>default вроде то что нужно для вас. можно его перенести в корень тада будет такое же поведение.
off: Тся, тся, будьте добры… и здесь и выше… да что ж такое…
насчет форм: я так понял, из того что я видел, так и нельзя создавать массив из вложенных форм и на него валидаторы навешивать? в динамических формах это часто используется. а когда вложений 2-3…
пример: большая форма заказа тура в отеле. можно заказать за раз сразу несколько номеров, в одном отеле, для разных людей. кроме этого, выбрать несколько опций. да еще для разных людей… в общем это жесть.
А еще довольно низкая манипуляция от Zend.
Сами же пишут о том, что ZF2 совершенно новый FW, и ТУТ ЖЕ «most popular». Когда он успел самым популярным стать, если не вышел еще?
Огромное количество вложение в array конфигах — раздражает. Новая архитектура форм… пока не очень. непривычно наверное.
Производительность — радует. Разделение модулей по группам — тоже. Возможность установки модулей как плагинов (и вообще система этих новых плагинов) — вроде все правильно сделали.
В общем… смешанные впечатления. ZF1 был хорош тем что его можно было доработать под себя как захочешь. Так что самая главная проверка должна быть практикой, на это у меня пока времени нет. Будем наблюдать.
По личному опыту, работая с конфигами этого DI ОЧЕНЬ ЧАСТО первое время путаешь уровень вложенности какого-то параметра, и потом долго и упорно «почему не работает как надо?». Отлаживать эти конфиги — да вообще никак.
Старый подход с бутстраппингом мне больше нравился.
Честно говоря, большой опыт работы с первым зендом оказался у меня бессилен перед новой структурой MVC во втором. Ребята круты конечно, но назвать теперь фреймворк easy & intutive теперь нельзя.
Судя по всему, проект заглох. Никаких серьёзных изменений за последние два месяца в проекте не было… в основном правки наподобие оптимизаций и чистки кода.
Все еще смотрю на проект с надеждой, но она тает с каждым днем. Пока продолжаю использовать те же сборочные скрипты (удобно и не нужно дополнительно ничего делать), своей модифицированной версии qbs (с возможностью сканирования директорий).
P.S. В переписке Йорг и Освальд… довольно агрессивно что ли, отнеслись к предложению каких-либо новшеств. Мне показалось слишком уж консервативно для такого молодого проекта, поэтому я плюнул на попытки ваять патчи для них. Может и зря.
Так я может не особо понял изначальную тему. Имелось в виду
double *array=new double[128]
против
std::listили
std::vector против std::list?
я как-то про второе подумал (для себя сравнив QList и QVector — да я знаю про сложность в QList, в векторе чуть быстрее все равно).
Первое что в голову приходит, данные для отображения таблицы к примеру.
Массив массивов какой-нибудь Variant было бы нормальным решением. Списки в стандартной реализации все же не идеальны в random access…
KISS по ним плачет.
Контроль типов там есть… но не там где нужно. мне бы лучше как раз в конфигурации все эти проверки были.
2) module/application/config/module.config
3) смотрим роут для application
4) child_routes=>default вроде то что нужно для вас. можно его перенести в корень тада будет такое же поведение.
насчет форм: я так понял, из того что я видел, так и нельзя создавать массив из вложенных форм и на него валидаторы навешивать? в динамических формах это часто используется. а когда вложений 2-3…
пример: большая форма заказа тура в отеле. можно заказать за раз сразу несколько номеров, в одном отеле, для разных людей. кроме этого, выбрать несколько опций. да еще для разных людей… в общем это жесть.
Сами же пишут о том, что ZF2 совершенно новый FW, и ТУТ ЖЕ «most popular». Когда он успел самым популярным стать, если не вышел еще?
Огромное количество вложение в array конфигах — раздражает. Новая архитектура форм… пока не очень. непривычно наверное.
Производительность — радует. Разделение модулей по группам — тоже. Возможность установки модулей как плагинов (и вообще система этих новых плагинов) — вроде все правильно сделали.
В общем… смешанные впечатления. ZF1 был хорош тем что его можно было доработать под себя как захочешь. Так что самая главная проверка должна быть практикой, на это у меня пока времени нет. Будем наблюдать.
Старый подход с бутстраппингом мне больше нравился.
belki.jpg
Все еще смотрю на проект с надеждой, но она тает с каждым днем. Пока продолжаю использовать те же сборочные скрипты (удобно и не нужно дополнительно ничего делать), своей модифицированной версии qbs (с возможностью сканирования директорий).
P.S. В переписке Йорг и Освальд… довольно агрессивно что ли, отнеслись к предложению каких-либо новшеств. Мне показалось слишком уж консервативно для такого молодого проекта, поэтому я плюнул на попытки ваять патчи для них. Может и зря.
Ждём разоблачительных постов про CSFR и переполнение буфера=)
По теме: новый «тренд» — супрематизм в интерфейсах! Реализм — прошлый век!
double *array=new double[128]
против
std::listили
std::vector против std::list?
я как-то про второе подумал (для себя сравнив QList и QVector — да я знаю про сложность в QList, в векторе чуть быстрее все равно).
Массив массивов какой-нибудь Variant было бы нормальным решением. Списки в стандартной реализации все же не идеальны в random access…