Как правильно пользоваться Zend Framework Programmer's Reference Guide?

Question

[usja]

Изучая Zend Framework по Quick Start всё легко и понятно. Даже этого достаточно, чтобы написать какой-то скрипт.
Если же этого не достаточно, можно использовать туториал от Роба Аллена, что внесёт полное понимание для старта использования ZF.

Но как только хочется начать использовать большие возможности, скажем Zend_Cache мы упираемся в описание с некими примерами кода, которые толком не понятно как правильно использовать. И так, почти со всеми модулями — описание, код есть, а логического примера с применением — нет. Поиск по интернету не даёт большей информации по ним.

%Хабраюзер%, а как ты используешь Programmer's Reference Guide и как понять каким образом правильно использовать функционал ZF?
Учитывая темпы развития ZF литература за ним явно не успевает. В сети есть книга «Zend Framework In Action», но всего на 199 страницах. Так же, буду благодарен на источники полезной информации.

Comments

[usja]

Список полезных сайтов:
Rob Allen Start — пишем простенький сайт с отображением, редактированием и добавлением данных
Zend Screen Casts

Answer 1

[3ds]

Посмотрите zendcasts.com там точно про кэш есть, и еще много чего, в том числе в одном из первых кастов он при вас ищет что то в документации на сайте. Хотя вроде там можно понять и так.

Comments

[usja]

Вы можете на примере, скажем Zend_Captcha что идёт во View, Model, controller.

Answer 2

[Владимир Чернышев]

Согласен, что документация оставляет какое-то двойственное впечатление, вроде прочёл, вроде понял как класс работает, но вот куда его воткнуть, хоть имя файла писали for example в примерах кода…

Сейчас (прямо сейчас :) ) дебагером лазаю по коду и смотрю куда то, что мне нужно, можно внедрить аккуратно. Так, в частности, ночью нашёл, что инициализацию роутинга логично вставить в бутстрап с помощью _init* (а самое смешное, когда нашёл, то смог уже найденный вариант нагуглить, но опять-таки на сторонних сайтах).

В общем, согласен с мнением, что ZF это, скорее, куча кирпичей, чем здание из них, которое нужно только отделать, а потому радует, что основной мой фреймворк symfony (сейчас вторую осваиваю), в котором можно легко использовать «кирпичи» ZF, вместо изобретения велосипедов, но при этом иметь хорошо документированное собственно здание :)

Comments

[usja]

Symfony предлагает очень качественный «фундамент» для старта. У них есть литература, которая действительно всё рассказывает.
У ZF, даже чтобы запустить их quick start, необходимо ковыряться, т.к. есть некоторые неточности.
Про роутинг в бутстрап я часто встречал. А вот как «кирпичики» ставить дальше? К 1.10 каких-то внятных примеров нет.
Есть уроки по созданию каких-то блогов и гостевых книг, но вот чтобы вылезти за рамки «говнокода»…

[Владимир Чернышев]

Мне, когда гуглил про роутинг, как-то попадались, как потом оказалось, примеры к старым версиям, то есть механику роутера я понял по этим статьям, но вот как её запустить… Сейчас вот дебагером ползаю по цепочке index.php -> вызов действия, чтобы найти лучшее место для работы с get/post параметрами, модифицирующими тело запроса до его прихода в контроллер.

Спасибо, кстати, за ссылку на туторил — сижу читаю

[Yeah]

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

resources.router.routes.domain.type = "Zend_Controller_Router_Route_Hostname"
resources.router.routes.domain.route = ":domain.example.com"
resources.router.routes.domain.chains.index.type = "Zend_Controller_Router_Route"
resources.router.routes.domain.chains.index.route = ":controller/:action/*"
resources.router.routes.domain.chains.index.defaults.controller = "index"
resources.router.routes.domain.chains.index.defaults.action = "index"

Это маршрутизатор доменов третьего уровня.

[Владимир Чернышев]

Пробовал через конфиги, но что-то не срослось с копипастом «абстрактного» примера из доков. Плюс очень, имхо, нечитабельно: простому CRUD контроллеру нужно 7 url'ов (если исходить из принципа «одно реальное действие — один метод Action»), 3 из которых с параметром id/slug/… 30+ длинных строк на один контроллер, да ещё все в одном глобальном .ini файле (вроде можно делать что-то вроде инклуда, но это опять разбираться надо где и как) — поддерживать такие конструкции, имхо, тяжеловато, в коде пускай строк не меньше, но куда читабельней