Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 158
Не каждый осилит такое, а 
dreikanter
Хорошо бы на хабре была подсветка кода, куда веселее читалось бы.
dreikanterХорошо бы на хабре была подсветка кода, куда веселее читалось бы.
Не когда не использовал фреймфорки, так как боюсь что при большой посещаемости, они будут создавать лишнюю нагрузку. Всё ищу статью, которая переубедит меня, никакак не найду. :(
Вместо того, чтобы искать, интереснее написать тесты самому для нескольких развитых фреймворков и погонять под нагрузкой. Результат, кстати, многим был бы интересен.
Ну "ищу" я бы в кавычки поставил, точнее сказать "надеюсь" что увижу.
А самому тесты некогда проводить. Ведь это нужно каждый фреймворк изучить, написать на нем не мало и потом погонять на крупном проекте. Не легкая задача...
А самому тесты некогда проводить. Ведь это нужно каждый фреймворк изучить, написать на нем не мало и потом погонять на крупном проекте. Не легкая задача...
Вот вам и тест
http://www.alrond.com/ru/2007/feb/04/dop…
http://www.alrond.com/ru/2007/feb/04/dop…
я конечно извиняюсь, но как может быть адекватен hello world для тестирования фрэймворка? Я могу написать cgi которая будет выводить тоже самое в 5 раз быстрее но это не значит что это 5 раз круче. Тестировать надо на реальных задачах, где функционал используется по полной.
мы говорим о фреймворке, а там подразумевается (по крайней мере в современных) модель MVC, а просто выводить "hello world" можно и парой строчек
Я представляю какую работу огромную надо провести, чтобы протестировать все фреймворки в "реальных" приложениях с реальной нагрузкой, с разными условиями, разными задачами...
Это задача для целой лаборатории, мой же тест позволяет оценить примерные позиции, так сказать для ознакомительных целей
Это задача для целой лаборатории, мой же тест позволяет оценить примерные позиции, так сказать для ознакомительных целей
А это первая часть
http://www.alrond.com/ru/2007/jan/25/rez…
http://www.alrond.com/ru/2007/jan/25/rez…
Тестировал сначала для себя,пока искал, с чем работать, потом решил добавить еще побольше фреймворков и всем выложить.
Вот такие фреймворки:
- CodeIgniter,
- Catalyst,
- Django, с psyco и без
- RubyOnRails,
- Symfony,
- Zend Framework,
- Pylons,
- CakePHP, с eAccelerator и без
- Turbogears with Cheetah, Jinja, Genshi
Вот такие фреймворки:
- CodeIgniter,
- Catalyst,
- Django, с psyco и без
- RubyOnRails,
- Symfony,
- Zend Framework,
- Pylons,
- CakePHP, с eAccelerator и без
- Turbogears with Cheetah, Jinja, Genshi
Сударь, вам не кажеться это идиотизмом тестировать фреймворки на отображение Hello World. Они не для того созданы. Понятное дело, что лучше всего показатели будут у голого РНР. Тогда зачем нужны все эти Зенды, Симфони, Кейки и пр. Если вы хотите провести более-менее объективное тестирование, а не Hello World (вы много писали реальных проектов, которые выводили Hello World?), напишите полноценное веб-приложение. На всех этих фреймворках. Сравните ко всем время обучнения, время написания, количество написанных строчек и пр. Фреймворк ускоряет и упрощает процесс разработки, не дает эстетам вывести Hello World.
В этом я полностью согласен с Фабиеном Потенсьером - разработчиком Симфони. Ссылку на его статью я уже тут выложил. Советую ознакомиться ;)
В этом я полностью согласен с Фабиеном Потенсьером - разработчиком Симфони. Ссылку на его статью я уже тут выложил. Советую ознакомиться ;)
между делом, хочу запостить небольшой обзор скорости работы модуля Zend_Cache по разным адаптерам. кто бы поднял карму, чтоб я мог это сделать?
Сударь, тесты были сделаны для тех, у кого есть голова на плечах и умеет делать выводы сам, а тех кто не понял целей всегда хватает.
Делал для своего выбора, после учета всех факторов, выбор был сделан, так что далее сравнивать мне это не интересно, тем более что никто это не оплачивает.
Делал для своего выбора, после учета всех факторов, выбор был сделан, так что далее сравнивать мне это не интересно, тем более что никто это не оплачивает.
Полностью согласен
Как правило там где большая нагрузка рулит кэш. И производительность фрэймворка уже не такой важный фактор.
Фрэймворк предоставляет дополнительные стандартные инструменты, которые позволяют значительно ускорить разработку проекта, систематизировать архитектуру, обеспечить отчуждаемость проекта. При этом среди дополнительных инструментов могут быть и те, которые ускоряют работу веб-прилоения, например, в ZF есть Zend_Cache, который, в свою очередь, предоставляет отличный API для работы с memcached и прочими бэкэндами кэша. Шустрая штука.
Насчет использования фреймворков мне больше всего понравилась статья разработчика Symfony
http://www.symfony-project.com/weblog/20…
Кстати:
"Yahoo! picked symfony for a 20 Million users application"
http://www.symfony-project.com/weblog/20…
Кстати:
"Yahoo! picked symfony for a 20 Million users application"
+1. От себя добавлю, что пока для PHP не появится компилятор, я не собираюсь использовать "универсальные" решения, позволяющие ускорить цикл разработки.
почему?
никакая оптимизация, prefetch, memcache не смогут обогнать изначально переведенные с humad-readble в bytecode алгоритмы. Если бы это было не так, то все модули для того-же php можно было бы смело писать на php, ведь суть-то не в том что они на C написаны, а в том, что они уже скомпилированы, адекватным для несущей ОС способом. В классическом оффлайн программировании язык вообще вторичен, там рулят компиляторы, чей компилятор качественнее переводит, те приложения и быстрее работают. Я бы с удовольствием писал все на C, но workflow уже положен на PHP, как на web-ориентированое средство разработки, поэтому я надеюсь. Жду и надеюсь.
P.S. Интересно за что столько минусов?
P.S. Интересно за что столько минусов?
Ты б уже на ассемблере писал. Для веб-программирования важна скорость разработки. Всё-таки программисты дороже, чем железо сервера
asm использовать нерационально. код вообще нечитаемый. Железо сервера безусловно дороже, но еще дороже scalability проекта, а это настолько индивидуальная вещь, что использование Framework может привести к проблемам.
Я думаю, никому из читающих не надо напоминать какие крупные проекты переживали кризис и переписывались с нуля из за непродуманной scalability. Я не против framework-ов, когда потолок посетителей ясен. Но если размер аудитории отсюда до завтрашнего утра, то я за фреймворк, подогнанный под задачи проекта.
Time-critical места в ресурсоемких приложениях или играх по прежнему пишутся на C или даже ASM.
PHP изначально появился как framework для перла. А теперь мы накручиваем на и без того толковый каркас еще какие-то? Зачем? Каких функций в PHP не хватает для разработки бизнес-логики?
Чем дороже программист, тем выше его квалификация по идее. Значит UML диаграммы, которая потом в каркас PHP-приложения построится будет достаточно для реализации.
Я думаю, никому из читающих не надо напоминать какие крупные проекты переживали кризис и переписывались с нуля из за непродуманной scalability. Я не против framework-ов, когда потолок посетителей ясен. Но если размер аудитории отсюда до завтрашнего утра, то я за фреймворк, подогнанный под задачи проекта.
Time-critical места в ресурсоемких приложениях или играх по прежнему пишутся на C или даже ASM.
PHP изначально появился как framework для перла. А теперь мы накручиваем на и без того толковый каркас еще какие-то? Зачем? Каких функций в PHP не хватает для разработки бизнес-логики?
Чем дороже программист, тем выше его квалификация по идее. Значит UML диаграммы, которая потом в каркас PHP-приложения построится будет достаточно для реализации.
Эти крупные проекты к тому времени успевали заработать либо кармы либо деньжат на свое переписывание.
Начни из делать изначально под высокие нагрузки - и не стали бы они крупными, потому что просто сил бы их доделать до вида, пригодного для использования, не хватило.
Начни из делать изначально под высокие нагрузки - и не стали бы они крупными, потому что просто сил бы их доделать до вида, пригодного для использования, не хватило.
то есть подумать о нагрузке изначально - дороже, чем думать о ней опосля?
Все зависит от того, сколько есть изначально ресурсов. И сколько наработок.
Но для многих проектов важно сначала проверить идею, если она оказалась востребована - можно найти ресурсы на рефакторинг, повышение производительности, новое железо и т.д.
Но для многих проектов важно сначала проверить идею, если она оказалась востребована - можно найти ресурсы на рефакторинг, повышение производительности, новое железо и т.д.
есть такое понятие, как premature optimization
перефразируя - о нагрузке надо думать когда начнет припекать.
запущенное в продакшн веб приложение покажет все затыки само по себе, оптимизация же заранее подобна борьбе с ветряными мельницами.
перефразируя - о нагрузке надо думать когда начнет припекать.
запущенное в продакшн веб приложение покажет все затыки само по себе, оптимизация же заранее подобна борьбе с ветряными мельницами.
Если люди придумали что-то хорошее для пользователей, а у них мало денег и времени? Им ничего не остается как можно быстрее и легче написать приложение, работающее хотя бы для тысячи пользователей, а потом уже на его основе привлечь деньги и человеческие ресурсы. Конечно в целом они потратят больше денег и времени на переработку, но изначально увы у них нет друго пути
Я бы с удовольствием подисскутировал на эту тему еще. Очень интересно послушать разнообразные мнения, но на публику работать я не хочу, и + и - просто отвлекают от вникания в аргументы. Я просто не понимаю смысла оценки, согласен - хорошо, не согласен - оппонируй. К тому-же на хабре есть группа, которая минусует меня по причинам, не относящимся к моим постам и комментам. Всем спасибо за полилог. На сем откланяюсь.
Фреймворк так или иначе постоянно дописывается(тот же zf позволяет почти везде это сделать) под конкретный проект. В общем то это основной путь развития любого фреймворка, так как его создатели не могут изначально определить все прецеденты.
Насчет того, чего нехватает в РНР я промолчу - "на вкус и цвет все фломастеры разные", но я не видел еще ни одного человека, который бы попробовал писать на высоком уровне на каком-то языке, а потом вернулся "вниз", не та производительность труда.
А ведь некоторые не рисуют подробных UML-диаграмм, только наброски (XP, TDD) =)
Насчет того, чего нехватает в РНР я промолчу - "на вкус и цвет все фломастеры разные", но я не видел еще ни одного человека, который бы попробовал писать на высоком уровне на каком-то языке, а потом вернулся "вниз", не та производительность труда.
А ведь некоторые не рисуют подробных UML-диаграмм, только наброски (XP, TDD) =)
положите opcode в кеш "на века"
Если есть руки - любой фреймворк можно "разогнать". Причём особых усилий для этого не нужно. Различными ухищрениями я умудрился разогнать зенд в 4 раза (с 20 до 80 req/s). Это и кеширование explain таблиц, кеширования frontcontroller состояние которого между запусками, даже на разных страницах в общем-то не меняется, кеширование. При этом у меня результаты бизнес-логики не кешируются вовсе. Кеш - в shmem (apc || xcache).
При этом ГОТОВЫЙ проект на Xeon 2.4GHz DualCore (4 CPU, 8 Cores) выдает 480 req/s. Т.е. приблизительно 50 req/s на ядро. Или 0.02 сек на запрос. Я нахожу это отличным результатом ;). Удобство разработки на фреймворке стоит куда дороже.
При этом ГОТОВЫЙ проект на Xeon 2.4GHz DualCore (4 CPU, 8 Cores) выдает 480 req/s. Т.е. приблизительно 50 req/s на ядро. Или 0.02 сек на запрос. Я нахожу это отличным результатом ;). Удобство разработки на фреймворке стоит куда дороже.
Спасибо за перевод!
Выглядит довольно просто, но как то не закончено. Возможно потому, что статья еще не вся :-). Реализация MVC стандартная и схожа со многими фремворками. Интересно знать на сколько он закончен и применим не только для блогов.
Сейчас активно интересуюсь Symfony. В основном, по причине хорошой документации. В принципе неплохо реализовали MVC. Активно используют конвенции. Настройки на yaml, но можно и xml.
ORM Propel и абстракция базы Creole.
Для рутинных операций (создание структуры папок, создание базовых классы моделей,CRUD)используются скрипты генерации.
Может у кого есть опыт реализации на Symfony приложений типа стандартного магазина с допустим купонами и афилейтами, комъюнити сайта (блог, форум, социальная сеть, приватные сообщения, личная галерея фоток, личное расписание, какая - нибудь тематическая начинка)?
Сейчас активно интересуюсь Symfony. В основном, по причине хорошой документации. В принципе неплохо реализовали MVC. Активно используют конвенции. Настройки на yaml, но можно и xml.
ORM Propel и абстракция базы Creole.
Для рутинных операций (создание структуры папок, создание базовых классы моделей,CRUD)используются скрипты генерации.
Может у кого есть опыт реализации на Symfony приложений типа стандартного магазина с допустим купонами и афилейтами, комъюнити сайта (блог, форум, социальная сеть, приватные сообщения, личная галерея фоток, личное расписание, какая - нибудь тематическая начинка)?
Плаигны к Симфони сейчас активно пишуться, а так... Пока РНР-фреймворки достаточно молодые и к ним нету нужного количества модулей.
Могу посоветовать Seagull PHP Framework. К нему написано гораздо больше модулей, и например, галерея, блог и ЛСки там есть. Советую глянуть.
Могу посоветовать Seagull PHP Framework. К нему написано гораздо больше модулей, и например, галерея, блог и ЛСки там есть. Советую глянуть.
Готовые решения не проблема. Я имел ввиду насколько эффективно при решении таких задач использовать symfony. По мне так лучше написать самому законченое приложение, чем подстраивать чужое. Всегда есть ньюансы, которые нужно доделать ручками.
Несколько лет пишу на собственном фреймворке, но что то он стал уже не модным :-) и захотелось что-нибудь эдакое с ORM, c генерацией и т.п.
Был короткий опыт работы с eZ, по моему норвежцы создали какого-то монстра.
Несколько лет пишу на собственном фреймворке, но что то он стал уже не модным :-) и захотелось что-нибудь эдакое с ORM, c генерацией и т.п.
Был короткий опыт работы с eZ, по моему норвежцы создали какого-то монстра.
Ну фреймворки без ORM уже действительно не воспринимаются. Я определяю так: если нужны стандартные элементы сайта, такие как: навигация, управление пользователями, управление блоками, CMS, галерея, блог, но при этом чтоб архитектура сайта была полноценным MVC-фреймворком (с поддержкой ORM), то я выберу Сигал. Если это приложение, которое практически не использует стандартный функционал сайта ( например, веб-сервисы), то я избрал бы Симфони.
Работали с eZ Publish или eZ Framework ? По поводу второго интересуют мнения.
Вторая половина статьи скоро будет :)
А сейчас обязательно припрется фанат Ruby/Java/Python и начнется очередной холивор :)
Пойду запасаться попкорном
Пойду запасаться попкорном
А чем Zend Framework лучше остальных, например CodeIgniter или CakePHP? Какие у него отличительные черты, преемущества?
Спасибо за перевод, из-за отсутствия именно туториала он довольно полезен.
Кстати, почему на устах не упоминается Seagull в списке фреймворков? :)
http://seagullproject.org/
Это все было сделано там еще 2-3 года назад, если не больше - отличная реализация паттерна MVC, контроллеры, экшины, валидаторы и т.д. Не знаю насколько проект развивается и поддерживается сейчас, но посмотреть на качественный код стоит.
А как с библиотеками классов у ZF - может кто знает? Абстракции это хорошо, но на одной модели не проживешь. Это дело времени конечно, просто не хотелось бы снова использовать PEAR.
Кстати, почему на устах не упоминается Seagull в списке фреймворков? :)
http://seagullproject.org/
Это все было сделано там еще 2-3 года назад, если не больше - отличная реализация паттерна MVC, контроллеры, экшины, валидаторы и т.д. Не знаю насколько проект развивается и поддерживается сейчас, но посмотреть на качественный код стоит.
А как с библиотеками классов у ZF - может кто знает? Абстракции это хорошо, но на одной модели не проживешь. Это дело времени конечно, просто не хотелось бы снова использовать PEAR.
В зенде есть минус, который достаточно трудно лечится ввиду концепции системы - использование схемы "один-класс-на-файл" и в результате - более 100-150 require-ных файлов во время работы. Из которых обычно процентов 90% вообще каждый запрос (!) таскаются. Даже при использовании opcode-кеширования на это уходит ~0.02сек на celeron 2.4ghz. На в-два-раза-более-шустром компе двухкратного преимущества в скорости при этом не будет ;). Даже отключением проверки изменений файлов в opcode-кешере проблема не решается.
Как вариант - для production собирать "особенный" билд проекта, впихнув в один файл, например, все зендовские классы которые грузятся каждый запрос. У меня получается 4.5-мб файлик с 12 тысячами строк %). При этом первый его require выходит в те же 0.02сек, а вот последующие (уже собранный из opcode-кеша) - 0.003сек, что уже вовсе не является критичным.
При создании такого зендовского файлика-библиотеки нельзя запихать туда весь зенд - иначе размер файла будет более 80мб и работать с ним нереально. При этом нужно высматривать процент загрузок на запрос, просматривая данные о кешах apd, xcache и тп. Вырезать из всех зендовских файлов комментарии и require_once (там их полно, особенно - на эксепшены). При определённом стечении обстоятельств - работает %).
Надо попробовать написать нормальный инструмент. Вообще хоть кто-нибудь сталкивался с проблемой скорости при использовании zend framework?
Как вариант - для production собирать "особенный" билд проекта, впихнув в один файл, например, все зендовские классы которые грузятся каждый запрос. У меня получается 4.5-мб файлик с 12 тысячами строк %). При этом первый его require выходит в те же 0.02сек, а вот последующие (уже собранный из opcode-кеша) - 0.003сек, что уже вовсе не является критичным.
При создании такого зендовского файлика-библиотеки нельзя запихать туда весь зенд - иначе размер файла будет более 80мб и работать с ним нереально. При этом нужно высматривать процент загрузок на запрос, просматривая данные о кешах apd, xcache и тп. Вырезать из всех зендовских файлов комментарии и require_once (там их полно, особенно - на эксепшены). При определённом стечении обстоятельств - работает %).
Надо попробовать написать нормальный инструмент. Вообще хоть кто-нибудь сталкивался с проблемой скорости при использовании zend framework?
они игнорируются интерпретатором ещё на стадии парсинга - поэтому влияние настолько мало, что лучше о нём и не думать :). Просто если что-то генерировать автоматически - то лучше обрезать всё что не нужно.
комментарии больше влияют на читабельность кода. если в файле строк кода очень много, легко запутаться. понятно что если критичен размер файла (тот же javascript код) то его лучше оптимизировать программой. уберет лишние символы пробелов, перевода строк и табуляции и уберет комментарии.
Я проводил тест для PHP4 и получил разницу во времени исполнения большого скрипта с комментариями и без около 15%. То-есть разница есть, и из тех скриптов, которые будут работать на production-сурверах лучше автоматически вычищать все комментарии и пустые строки.
да, сталкивался
я активно использовался __autoload вместе с Zend::loadClass ещё на старой версии, и ещё много неособо приятных вещей, когда занялся тестами скорости по началу был в диком ужасе )
тоже очень сильно раздразжали пару сотенные инклуды при зарпосах, но решать эту проблему времени
было мало к сожалению, ваше решение натолкнуло на мысли, обязательно его испробую, спасибо
кстати в последних релизах разработчики зенда и сами начали коечего кешировать,
теже схемы базы в Zend_Db, из ваших слов я понял вам пришлось делать это руками
я активно использовался __autoload вместе с Zend::loadClass ещё на старой версии, и ещё много неособо приятных вещей, когда занялся тестами скорости по началу был в диком ужасе )
тоже очень сильно раздразжали пару сотенные инклуды при зарпосах, но решать эту проблему времени
было мало к сожалению, ваше решение натолкнуло на мысли, обязательно его испробую, спасибо
кстати в последних релизах разработчики зенда и сами начали коечего кешировать,
теже схемы базы в Zend_Db, из ваших слов я понял вам пришлось делать это руками
зенд зендом, но я добрую половину переписал/дописал. ООП сила, брат.
тем не менее, очень радуюсь когда что-то такое же как и самописное имплементируют зендовцы :). Я с ним дружу с 0.4 версии и уже неоднократно это было. Только что глянул в Zend_Db, действительно кеш метадаты там теперь есть. Почти зеркальная копия моего :-P
тем не менее, очень радуюсь когда что-то такое же как и самописное имплементируют зендовцы :). Я с ним дружу с 0.4 версии и уже неоднократно это было. Только что глянул в Zend_Db, действительно кеш метадаты там теперь есть. Почти зеркальная копия моего :-P
я тоже давно использую фреймворк ) практически с первых релизов, очень интересно было наблюдать за его эволюцией, порою многие вещи люди просто кординально переделывали
например я только сделал реализацию валидаторов под себя, в ледующем релизе появились очень приятные изменения в этом пакете )
а ООП да, сила, но как любая сила, должна использоватся с умом =)
например я только сделал реализацию валидаторов под себя, в ледующем релизе появились очень приятные изменения в этом пакете )
а ООП да, сила, но как любая сила, должна использоватся с умом =)
Кстати, а вышеупомянутый Seagull Framework умеет автоматически собирать все нужные библиотеки в единый файл. Может и в Зенде до такого додумаются...
Такая схема уже давно реализована во многих проектах. Взгляните на Doctrine или TYPO3.
да, меня самого удручает скорость работы ZF. Решение проблемы тут: Сборка инклюдов в один файл
А возможно ли юзать шаблониаторы, к примеру SMARTY ?
Да, разработчики зенд много пишут о том как использовать другие шаблонизаторы в представлениях
суть решения в разработке своего обёртки под smarty, реализующей интерфейс Zend_View
почтитать можно
devzone и документация к зенду
суть решения в разработке своего обёртки под smarty, реализующей интерфейс Zend_View
почтитать можно
devzone и документация к зенду
да, легко.
нужно разве что будет написать свой класс View, имплементируя методы Zend_View_Interface. В мануале зенда об этом рассказано.
нужно разве что будет написать свой класс View, имплементируя методы Zend_View_Interface. В мануале зенда об этом рассказано.
Лучшее сравнение фрэймворков из тех что я видел
http://video.google.com/videoplay?docid=6297126166376226181
Сравниваются:
- J2EE (Java)
- Ruby on Rails (Rubin)
- Zope/Plone (Python)
- Turbogears (Python)
- Django (Python)
Извините если баян
http://video.google.com/videoplay?docid=6297126166376226181
Сравниваются:
- J2EE (Java)
- Ruby on Rails (Rubin)
- Zope/Plone (Python)
- Turbogears (Python)
- Django (Python)
Извините если баян
Спасибо за перевод!
Неплохое руководство-описание ZendFramework (и не только) можно найти еще тут
Неплохое руководство-описание ZendFramework (и не только) можно найти еще тут
.. "не для кого не являются секртеом" .. секртеом - секретом // опечатка
и во многих отношениях постепенно становитс лучше.
оперчаточка, становится
хммм, все эти тесты, все эти выиграшы в секундах... кому они нужны? главное чтобы человеку было удобно работать в фреймворке. я очень нехотя и со скрипом перелез на rebyonrails, но когда немного в всём разобрался был счастлив до безумия, и многие вещи поражают до сих пор, и плагины появляются очень быстро, вобщем я сильно уменьшил время на разработку какого либо приложения. теперь когда я проно уселся на рельсах, появилось очень много, черезвычайно хороших фреймворков для php. вывод только один, кто кодит на пхп, тому нет смысла перелезать на руби, это займёто больше времени, проще разобраться в фреймворке...
на а как сильно эти фреймворки грузят проц.... с каждым годом процесорные мощности всё больше, хостинг всё дешевле, да и вообще вы, что яндексы собрались писать?)
на а как сильно эти фреймворки грузят проц.... с каждым годом процесорные мощности всё больше, хостинг всё дешевле, да и вообще вы, что яндексы собрались писать?)
Приведенные примеры были протестирован на Zend Framework версии 1.0.0. Вероятнее всего, они так же будут работать с более поздними версиями, но не с более ранние.
Вероятнее всего -> Скорее всего
так же — просто выкинуть!
с более -> и с более
ранние -> ранними
Вероятнее всего, они так же будут работать с более поздними версиями, но не с более ранние.
Правильно, кажется, ранними
Правильно, кажется, ранними
Обязательно сегодня вечером почитаю, рад, что наконец кто-то заговорил про MVC.
огромное спасибо за статью. давно искал
Будет ли во второй части рассказано про роутинг внутри приложения?
Хоть я недолюбливаю PHP, но аффтару Респект!
Сразу предложу материал для дальнейшего развития фреймворка:
1. Желательно вынести конфигурацию сайта и page-flow за пределы кода в конфигурационный файл и немного отделить декларативную часть от имплементации.
2. Весчь, которой не хватает в Struts и которая есть в JSF: events. Отличаются от экшнов тем, что только меняют состояние активной страницы, но при этом не осуществляют перехода на другую и не делают никаких значимых действий. Например если у меня на странице есть компонент типа дерева, с динамической подгрузкой scopes, открытие юзером поддерева делает рефреш страницы и посылает контроллеру событие. Контроллер вытаскивает из модели необходимые для поддерева данные и страница рендерится заново с новыми изменениями.
3. Помимо View ввести понятие компонента, который имеет свой рендерер, контроллер и модель, и преставляет собой отдельный (reusable) элемент интерфейса (но более сложный, чем стандартные html). Одни и те же компоненты могут использоваться в различных Views. Экшн-контроллер может принимать события от компонента, а также ессно обмениваться с ним данными. Изменение состояния компонента может осуществляться либо через JavaScript, либо через refresh страницы, либо используя Ajax.
4. Ajax-интеграция для компонентов.
5. Библиотека стандартных компонентов (элементов интерфейса) была бы только плюсом.
Хороший пример подобной библиотеки лежит здесь: http://myfaces.apache.org/tomahawk/
Сразу предложу материал для дальнейшего развития фреймворка:
1. Желательно вынести конфигурацию сайта и page-flow за пределы кода в конфигурационный файл и немного отделить декларативную часть от имплементации.
2. Весчь, которой не хватает в Struts и которая есть в JSF: events. Отличаются от экшнов тем, что только меняют состояние активной страницы, но при этом не осуществляют перехода на другую и не делают никаких значимых действий. Например если у меня на странице есть компонент типа дерева, с динамической подгрузкой scopes, открытие юзером поддерева делает рефреш страницы и посылает контроллеру событие. Контроллер вытаскивает из модели необходимые для поддерева данные и страница рендерится заново с новыми изменениями.
3. Помимо View ввести понятие компонента, который имеет свой рендерер, контроллер и модель, и преставляет собой отдельный (reusable) элемент интерфейса (но более сложный, чем стандартные html). Одни и те же компоненты могут использоваться в различных Views. Экшн-контроллер может принимать события от компонента, а также ессно обмениваться с ним данными. Изменение состояния компонента может осуществляться либо через JavaScript, либо через refresh страницы, либо используя Ajax.
4. Ajax-интеграция для компонентов.
5. Библиотека стандартных компонентов (элементов интерфейса) была бы только плюсом.
Хороший пример подобной библиотеки лежит здесь: http://myfaces.apache.org/tomahawk/
1. очень легко реализуется на Zend_Config. Поддерживаются namespaces
2,3,4. Не очень хороший пример насчет событий, т.к. я бы, например, использовал AJAX :) А вообще событийная модель пока слишком "высокая" фича для ZF. Не все сразу, слишком высокие требования к коду. Вот только сейчас до composite view добрались.
5. Уже есть - Zend_View_Helper
2,3,4. Не очень хороший пример насчет событий, т.к. я бы, например, использовал AJAX :) А вообще событийная модель пока слишком "высокая" фича для ZF. Не все сразу, слишком высокие требования к коду. Вот только сейчас до composite view добрались.
5. Уже есть - Zend_View_Helper
Вот-вот. Визуальные компоненты нужны... с event'ами...
В разработке "личного фреймворка" этим сейчас занимаюсь.
Жалко лишь что box-модель в html/css такая уродливая... чтобы боксы вели себя так, как принято в нормальных программных интерфейсных библиотеках - нужно извращатся дай боже.
В разработке "личного фреймворка" этим сейчас занимаюсь.
Жалко лишь что box-модель в html/css такая уродливая... чтобы боксы вели себя так, как принято в нормальных программных интерфейсных библиотеках - нужно извращатся дай боже.
Я сейчас участвую в разработке новой версии одного из самых посещаемых в Германии порталов. Решили использовать Зенд Фреймворк, расширив его основательно. В ходе разработки все больше родных библиотек Зенда выпадают из-за того, что содержат много лишнего ненужного оверхеда или попросту не подходят для решения конкретных задач.
немного оффтоп: К нам недавно приезжали из Зенда, рекламировать свои продукты. кроме всего прочего всучили альфа версию Зенд Студии Неон, которая основывается на Еклипсе теперь. Пока ничего конкретного сказать не могу - много удобных вещей, но и зависла уже пару раз. При использовании Зенд Платформы мне кажется незаменима.
немного оффтоп: К нам недавно приезжали из Зенда, рекламировать свои продукты. кроме всего прочего всучили альфа версию Зенд Студии Неон, которая основывается на Еклипсе теперь. Пока ничего конкретного сказать не могу - много удобных вещей, но и зависла уже пару раз. При использовании Зенд Платформы мне кажется незаменима.
Любой фреймворк это основа, и при постоянном развитии его постепенная замена своим кодом неизбежна. Чем лучше фреймворк, тем дольше он будет удовлетворять потребностям, и тем меньше будет "сковывать" разработчиков. Узкозаточенный код (с малым количеством абстракций) всегда работает лучше гибкого. Он правится хуже, и пишется дольше.
Вы согласны?
Вы согласны?
Очень интересно было бы увидеть обзор со скринщотами.
вообще есть куча проблем/вопросов по ZF, где их лучше всего задать ?
может кто поделится кодом "приложения" на ZF ? Жутко интересно как другие реализовывают, например, авторизацию...
может кто поделится кодом "приложения" на ZF ? Жутко интересно как другие реализовывают, например, авторизацию...
Выше в камментариях есть два примера. На самом деле в ZF вникнуть и освоится действительно не очень просто. Да можно прочитать этот tutorial, но дальше снова дело идет не очень хорошо. К примеру чтобы написать обработку несуществующего контроллера и выдать страницу вроде "404 Извините, неверный урл." нужно обрабатывать исключения. Чтобы сделать урлы не /контроллер/действие/параметры, а просто /действие/параметры нужно серьезно ковырятся в роутере. И так все время идет наследование зендовских классов под свои задачи. В итоге получается не слишком удобная разработка, пока не образуется некая собсвенная надстройка над ZF. И производительность от всего этого тоже немного страдает. В тот же cakephp гараздо проще войти, может быть он не такой гибкий, но он более интуитивно понятный. Или в zf паттерны более привычные например java-разработчикам? Может быть просто дело привычки?
Неплохо перевели. Только жалко, блин, я этот туториал я уже на английском изучил.
Можно и я тоже ляпну свое?
Вот это функция позволяет не вызывать постоянно Zend_Loader
Прописываем ее в index.php, а потом можно сразу создавать классы, не подключая их.
Можно и я тоже ляпну свое?
Вот это функция позволяет не вызывать постоянно Zend_Loader
function __autoload($class) {
Zend_Loader::autoload($class);
}Прописываем ее в index.php, а потом можно сразу создавать классы, не подключая их.
доброе утро :)
:-) будьте внимательны
Zend_Loader::registerAutoload();
:-) будьте внимательны
Доброe. :)
У меня и так работает.
У меня и так работает.
а зачем вы ZendFramework используете? :)
Я не вижу разницы между двумя методами(класса), если результат и цель одни и те же.
а если посмотреть чуть глубже и сообразить, что если в версии выше 1.0 они что-то переделают, то и способ подставки в autoload тоже переделают. А вам придётся постоянно дублировать их функциональность. Я уже не говорю о стандартизации и удобном понимании вашего кода другими разработчиками знакомыми с ZendFramework :).
У меня это работало до той поры пока я не начал использовать модульную структуру проекта, у меня __autoload почему-то сlass News_IndexController искал в дефолтном каталоге а не в каталоге news. Zend_Loader::registerAutoload(); - решило проблему
да, кстати. Работая с Зендом всегда нужно иметь ввиду - если возникает какая-то идея по поводу реализации какой-то фичи, то в 90% случаев это уже есть в зенде либо скоро будет. По крайней мере ленится и периодически заглядывать в сёрсы зенды (поучится хотя бы :)) явно не нужно.
Огромное спасибо за статью. Как раз собирался найти что-нибудь подобное по ZF, и тут как гром с неба! :)
Вообще Zend_Db_Table очень удобная вещь. Настраивается намного легче чем Hibernate. Для постгрес добавить sequence только одна строка. Вот только не знаю, что из них быстрее работает. Никто не делал тестов?
И еще, что выступает в роли pconnect-a, т.е пула?
И еще, что выступает в роли pconnect-a, т.е пула?
Я сейчас нахожусь в поиске простого и гибкого фреймворка для создания несложных сайтов с интуитивной и простой админкой, где использование Друпала не совсем оправдано.
Zend Framework отталкивает своим размером, и "многословностью", столь любимой некоторыми ярыми приверженцами ООП (я говорю про названия типа Zend_Framework_My_Super_Mega_Class_For_Validation, 1 file = 1 class, размером в 15 мегов!) как-то все это тяжело воспринять после милого сердцу Drupal'a..
Посмотрел CakePHP, оттолкнул ORM и automagic, гибкости не хватило на примитивнейший пример где в таблицу для many-to-many связи надо было воткнуть дополнительное поле - для этого пришлось копаться и мучаться.(Было это полгода назад примерно, может сейчас cakePHP такое и умеет, но пример характерный) Вообще я ORM не верю, даже Django имеет какие-то "детские" проблемы типа не поддерживаемой агрегации. Я конечно понимаю что все можно "дописать" - но мне не нравится ощущение, что какой-то большой кусок кода не справляется с такой простой задачей и лежит мертвым грузом в моем приложении.
Посмотрел CodeIgniter - понравилось больше, работает очень быстро, есть scaffolding и нет orm, подключает только те файлы, которые нужны, простые вещи не усложняет практически. ActiveRecord мне противен, но пусть уж будет, можно забить и юзать старый добрый sql везде. Насторожило то, что фреймворк попал под владение Ellis Labs, и судя по всему это несколько затормозило разработку - это повело за собой почкование Kohana, based on CI платформы, разработкой которого вроде как должно заниматься коммунити. Из-за некоторых непонятных и неоднозначных вещей, которые мне открылись ( http://codeigniter.com/forums/viewthread… ) - я пожалуй и от этого фреймворка откажусь.
Вчера посмотрел Symfony - понравился yaml, очень понравилась уже готовая система валидации, но не понравились вещи типа усложненного создания проекта, массивности, низкой скорости (хотя автору в вышеупомянутой статье про скорость системы склонен верить)
Короче хотелось чего-то простого, элегантного и мощного, надеюсь на что-то, но, видимо, буду дописывать свое, своровав идеи с валидацией у CI и symfony... надо Seagull ради интереса еще поглядеть
Zend Framework отталкивает своим размером, и "многословностью", столь любимой некоторыми ярыми приверженцами ООП (я говорю про названия типа Zend_Framework_My_Super_Mega_Class_For_Validation, 1 file = 1 class, размером в 15 мегов!) как-то все это тяжело воспринять после милого сердцу Drupal'a..
Посмотрел CakePHP, оттолкнул ORM и automagic, гибкости не хватило на примитивнейший пример где в таблицу для many-to-many связи надо было воткнуть дополнительное поле - для этого пришлось копаться и мучаться.(Было это полгода назад примерно, может сейчас cakePHP такое и умеет, но пример характерный) Вообще я ORM не верю, даже Django имеет какие-то "детские" проблемы типа не поддерживаемой агрегации. Я конечно понимаю что все можно "дописать" - но мне не нравится ощущение, что какой-то большой кусок кода не справляется с такой простой задачей и лежит мертвым грузом в моем приложении.
Посмотрел CodeIgniter - понравилось больше, работает очень быстро, есть scaffolding и нет orm, подключает только те файлы, которые нужны, простые вещи не усложняет практически. ActiveRecord мне противен, но пусть уж будет, можно забить и юзать старый добрый sql везде. Насторожило то, что фреймворк попал под владение Ellis Labs, и судя по всему это несколько затормозило разработку - это повело за собой почкование Kohana, based on CI платформы, разработкой которого вроде как должно заниматься коммунити. Из-за некоторых непонятных и неоднозначных вещей, которые мне открылись ( http://codeigniter.com/forums/viewthread… ) - я пожалуй и от этого фреймворка откажусь.
Вчера посмотрел Symfony - понравился yaml, очень понравилась уже готовая система валидации, но не понравились вещи типа усложненного создания проекта, массивности, низкой скорости (хотя автору в вышеупомянутой статье про скорость системы склонен верить)
Короче хотелось чего-то простого, элегантного и мощного, надеюсь на что-то, но, видимо, буду дописывать свое, своровав идеи с валидацией у CI и symfony... надо Seagull ради интереса еще поглядеть
Про Cake не совсем понял. Подробнее не объясните?
когда дошел о того места где надо добавить
$album = new Album();
$this->view->albums = $album->fetchAll();
вылезает ошибка
Fatal error: Uncaught exception 'Zend_Db_Adapter_Exception' with message 'The PDO extension is required for this adapter but not loaded' in z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php:95 Stack trace: #0 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Abstract.php(246): Zend_Db_Adapter_Pdo_Abstract->_connect() #1 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php(206): Zend_Db_Adapter_Abstract->query('DESCRIBE `album...', Array) #2 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Mysql.php(88): Zend_Db_Adapter_Pdo_Abstract->query('DESCRIBE `album...') #3 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(595): Zend_Db_Adapter_Pdo_Mysql->describeTable('album', NULL) #4 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(528): Zend_Db_Table_Abstract->_setupMetadata() #5 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(264): Zend_Db_Table_Abstract->_setup() #6 z:\home\zf\www\zf-tutorial\application\controllers\IndexController.php(12): Zend_Db_ in z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php on line 95
$album = new Album();
$this->view->albums = $album->fetchAll();
вылезает ошибка
Fatal error: Uncaught exception 'Zend_Db_Adapter_Exception' with message 'The PDO extension is required for this adapter but not loaded' in z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php:95 Stack trace: #0 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Abstract.php(246): Zend_Db_Adapter_Pdo_Abstract->_connect() #1 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php(206): Zend_Db_Adapter_Abstract->query('DESCRIBE `album...', Array) #2 z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Mysql.php(88): Zend_Db_Adapter_Pdo_Abstract->query('DESCRIBE `album...') #3 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(595): Zend_Db_Adapter_Pdo_Mysql->describeTable('album', NULL) #4 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(528): Zend_Db_Table_Abstract->_setupMetadata() #5 z:\home\zf\www\zf-tutorial\library\Zend\Db\Table\Abstract.php(264): Zend_Db_Table_Abstract->_setup() #6 z:\home\zf\www\zf-tutorial\application\controllers\IndexController.php(12): Zend_Db_ in z:\home\zf\www\zf-tutorial\library\Zend\Db\Adapter\Pdo\Abstract.php on line 95
Та же ерунда ( Что делать?
Пол ночи сидел, но разобрался. ДУмаю кому-нибудь пригодится знать, что всё дело в версии ПХП, а точнее в его комплектации. Просто поставьте версию поновее и всё будет ок
Я забил....и перешел на СакеРНР.....
только не надо учить Саке используя материалы с Хабра.....т.к. они только отпугивают чеорвека от Саке.
лучше учите с Cakephp
только не надо учить Саке используя материалы с Хабра.....т.к. они только отпугивают чеорвека от Саке.
лучше учите с Cakephp
Поставить расширение PDO для PHP =)
в коде примера ошибка:
set_include_path('.'.PATH_SEPARATOR. './library'
заменить на
set_include_path('.'.PATH_SEPARATOR. './application/library'
set_include_path('.'.PATH_SEPARATOR. './library'
заменить на
set_include_path('.'.PATH_SEPARATOR. './application/library'
Спасибо за перевод, интересно!
Опечатка:
>>закрытие блока PHP кода ?<
< меняем на >
Опечатка:
>>закрытие блока PHP кода ?<
< меняем на >
>> У Zend Framework следующие требования:
>> PHP версии 5.1.4 или выше;
>> Веб-сервер, поддерживающий mod_rewrite.
Роб, ты неправ...
Mod_rewrite не является необходимым, он лишь добавляет удобства
>> PHP версии 5.1.4 или выше;
>> Веб-сервер, поддерживающий mod_rewrite.
Роб, ты неправ...
Mod_rewrite не является необходимым, он лишь добавляет удобства
если уж использовать PHP в качестве html-шаблонизатора..( то лучшие вместо
render('header.phtml'); ?>
escape($this->title); ?>
render('footer.phtml'); ?>
использовать более компактные конструкции языка:
render('header.phtml') ?>
escape($this->title) ?>
render('footer.phtml') ?>
render('header.phtml'); ?>
escape($this->title); ?>
render('footer.phtml'); ?>
использовать более компактные конструкции языка:
render('header.phtml') ?>
escape($this->title) ?>
render('footer.phtml') ?>
Помогите пожалуйста нубу.
Вот это:
render('header.phtml'); ?>
escape($this->title); ?>
render('footer.phtml'); ?>
повторяется в 4 файлах. Как можно это сократить до одного файла?
И в каком файле вообще собирать все части сайта?
Допустим у меня есть блок авторизации и блок новостей. Соответственно в виде авторизации я хочу добавить только авторизацию, а в новостях новости без всяких " ..."
Затем это всё скрепить воедино. Где?
Вот это:
render('header.phtml'); ?>
escape($this->title); ?>
render('footer.phtml'); ?>
повторяется в 4 файлах. Как можно это сократить до одного файла?
И в каком файле вообще собирать все части сайта?
Допустим у меня есть блок авторизации и блок новостей. Соответственно в виде авторизации я хочу добавить только авторизацию, а в новостях новости без всяких " ..."
Затем это всё скрепить воедино. Где?
В общем вопрос в том как сделать общий каркас для всех страниц и чтобы в него уже вставлять отдельные визуалные компоненты?
И вообще я немного не понял. В примере рассмотрен случай, когда у нас на странице страница выполняющая конкретное действие. Добавить/удалить/обновить/посмотреть. А как быть с теми модулями, которые должны присутствовать на всех страницах? Причём эти модули должны тоже выполнять какой-то php-код и тупо пихать в каждый Вид не выгодно.
Прочитав продолжение ответ так и не нашёл ( помогите пожалуйста разобраться. Впринципе все мои три коммента об одном и том же
Прочитав продолжение ответ так и не нашёл ( помогите пожалуйста разобраться. Впринципе все мои три коммента об одном и том же
Я использовал вот этот класс: http://my.opera.com/zomg/blog/2007/09/14…
"Каркасы" называются обычно Layout-ами, файлами задающими общий вид страницы, в них можно воткнуть несколько "модулей", оформленных в виде хелперов. Есть и другие способы ( http://akrabat.com/2007/07/11/two-step-v… ), но я пока не заморачивался.
"Каркасы" называются обычно Layout-ами, файлами задающими общий вид страницы, в них можно воткнуть несколько "модулей", оформленных в виде хелперов. Есть и другие способы ( http://akrabat.com/2007/07/11/two-step-v… ), но я пока не заморачивался.
У вас неправильно отформатирована структура каталогов.
library/ и public/ должны быть на одном уровне с application/.
library/ и public/ должны быть на одном уровне с application/.
Это не единственная ошибка в статье. Также после создания контроллера предлагается протестировать задавая адреса http://localhost/zf-tutorial/ и.т.д в оригинале же написано:
We have now set up the four actions that we want to use. They won’t work yet until we set up
the views. То есть пока не будут готовы views эти адреса работать не будут.
We have now set up the four actions that we want to use. They won’t work yet until we set up
the views. То есть пока не будут готовы views эти адреса работать не будут.
Спасибо за статью, получилось конечно все не сразу, но эта статья очень помогла мне)))
больше всего мучался с поддержкой mysql, так что если у кого из новичков, как я, возникнут вопросы на эту тему -обращайтесь..)
больше всего мучался с поддержкой mysql, так что если у кого из новичков, как я, возникнут вопросы на эту тему -обращайтесь..)
Исправь структуру каталога. Там выходит что все находится в папка application. application, library, public - должны находится в одной директории. Я понимаю, что каждый пишет как ему удобно. Но так, как ты пишешь начальным пользователям, которые явно будут пользоватся мануалом на офф сайте, то ИМХО лучше придерживаться структуры, которую дают там.
Ошибка: «Приведенные примеры были протестирован» — надо — протестированы.
Статья уже сильно устарела. Очень хотелось бы увидеть какой нибудь пример приложения, разработанный на зенде > 1.9.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в Zend Framework