Zend Framework первой свежести, ч1: зендируем MVC

    Меня тут разбанили по просьбе Дина, и я решил принести пользу обществу. Поскольку я дурак и ничего не умею, дай, думаю, напишу о ZF — офигенной штуке, которую все почему-то искренне ненавидят. Надо успеть, правда, пока по НТВ не стали показывать Пелевина (жаль, ненастоящего).

    Главная беда всевозможных QS в том, что они действительно quick и действительно start, но если делать все как там, получится не особенно «масштабируемое» приложение, с которым не очень понятно, что делать. По сравнению с официальным quickstart'ом прошлой версии Zend Framework'a, новый просто великолепен, но не лишен недостатков. Я пойду с другого конца: вместо того, чтобы обьяснять, как сделать что-то бессмысленное и типовое, попробую (!) рассказать, как писать приложение вообще, используя всевозможными способами Zend Framework. А, пора хабракат делать.

    Zend Framework — волшебный и счастливый фреймворк на языке PHP для настоящих мужиков ( ;-) ). Для меня ZF — единственная возможность написать легкодописываемое, масштабирумое и вполне сопроводимое веб-приложение за очень короткий срок (часов за 6 легко делается без особого напряга набор авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем), выгодно отличающееся от решений, где вообще почти ничего делать не придется (Wordpress, Drupal, ...) тем, что программисту не навязывается ничегошеньки вообще: ZF, в принципе, набор связанных между собой классов: использовать можно только те, которые хочется, сохраняя тот стиль разработки, который вам больше нравится. Вам не хочется использовать Zend_Auth для авторизации? А кто вам запретит написать своё что-нибудь? ;) При этом, он красиво и очень логично построен (классы всякие, паренты, интерфейсы, вся фигня): его удобно переписывать, например, просто унаследовав какой-нибудь свой класс от стандартного зендовского и дописав то, чего так хочется дописать (только не устраивайте в комментах холиваров «ZF против чего-нибудь». Пожалуйста. Вообще не устраивайте).

    Ага! Итак, то, что у нас будет получаться, будет (надеюсь) сложновато, но логично и более-менее красиво: будет легко доработать и легко понять, где у нас что. Я — идиот и дилетант, а потому никак не могу претендовать на то, что все мои ходы действительно разумны, правильны и что я использую все возможности: за ценные советы, добавления, опровержения буду говорить «спасибо» и так далее. Ах да, и я думаю, что одной статьей тут дело не ограничится. Более того, первая может показаться достаточно банальной, в таком случае подождите вторую 8) Конкретно в этой я буду рассказывать о работе с Zend'овской реализацией MVC, позже буду придерживаться ее же, но надеюсь не забыть о труженниках, которым она не нравится.

    Решил повториться: «Я не хакер, я только учусь». Знаете лучше? Давайте перепишем эту/напишем следующую статью вместе, так, чтобы было еще круче ;-)

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

    Поехали!

    Первым делом стоит скачать ZF, а потом пробежаться по квикстарту, хотя бы до «Create a Configuration and Registry». Потом идет какая-то фигня с SQLite (я никогда не пойму смысла скьюлайта), а дальше вообще используется Zend_Form (я противник такого рода развлечений, сорьке — весь html будем писать ручками или просить об этом верстальщиков, если хотите, разбирайтесь с ним сами, ничего сложного нету). От того костяка, что у вас получится, мы и будем плясать.

    Итак, у нас есть примерно следующее (чего нет — досоздайте, если чего лишнее — ну сами придумайте, что с этим делать):
    + application/
      + config/
        * app.ini
      + controllers/
        * IndexController.php
    	* ErrorController.php
      + layouts/
    	+ scripts/
    	  * layout.html
    	+ helpers/
      + models/
    	+ dbtable/
    	* SuperModel.php
      + views/
        + scripts/
    	  + index/
    	    * index.phtml
          + error/
    	    * error.phtml
    	+ helpers/
      * routes.php [1]
      * bootstrap.php
    + library/ // [2]
      + zend/
    	// тру-ля-ля...
    + public/ (он же htdocs/ у меня, но это неважно)
      + static/
        // [3]
      * index.php
    


    [1] — в этом фаиле находятся все роуты. Он инклудится потом в bootstrap.php (после qs роуты должны идти в самом бутстрапе, но обычно у меня их многовато выходит)
    [2] — я бы вынес эту папку на уровень выше, то есть, скажем, если у вас это все в /home/va1en0k/coolsite.ru/, то почему бы не держать библиотеки в /home/va1en0k/library/ вместо /home/va1en0k/coolsite.ru/library/: остальным прогам будет легче до них добраться
    [3] — тут будут разные крутые фаилы CSS, JS, картинки — вся байда. Их можно разнести по styles/, images/, можно вынести на какой-нибудь другой сервер, никто не заставляет держать их здесь: HTML-то весь мы сами пишем

    Все достаточно просто, обычный MVC. Алгоритм написания программы такой (он несколько не похож на «разработку через тестирование», которую так все любят, но, в принципе, можно устраивать тесты вида, контроллера и модели до/после/во время их разработки):
    1. Для начала, нам нужно нечто, происходящее при определенном действии юзера: нас об этом дизайнер попросил или там еще что-нибудь;
    2. Действие — всегда вызов урла какого-нибудь. Придумываем урл (он может быть любой, но мы все очень радуемся урлам вида /«controller_name»/«action_name». Но, скажем, для получения поста лучше какой-нибудь такой: /post/12321, не правда ли?), решаем, каким он будет обрабатываться контроллером (никакой не подходит? Создаем новый в /application/controllers/), добавляем к этому контроллеру действие;
    3. Создаем /views/scripts/назване_контроллера/название_действия.phtml, рисуем там нужный нам html;
      • Там где надо вывести что-то, что не выводится на других страницах, так и пишем: <?=$this->shachlo?>, записываем или запоминаем, что нам нужно;
      • Там где надо вывести что-то, что выводится много где, например, имя какого-нибудь пользователя, пишем что-то вроде <?=$this->printUser($this->user)?>;

    4. Теперь идем и создаем все хелперы, которые нам нужны (хелперы — это функции, которые вызываются так: <?=$this->printUser($this->user)?>). Их пишем в /views/helpers/. Лучше выносить их отдельно для того, чтобы можно было в любой момент к именам юзеров добавить какую-нибудь иконку или применить какой-нибудь еще стиль. Или заменить их все на слово ЩАЧЛО, чтобы все юзеры просто охренели от удивления! %)
    5. Подпрыгивая от счастья, пишем действие. Весь код действия можно (почему бы, собственно, не) делить на 3 части:
      • Разбираемся с аргументами: получаем данные из форм или там из урла (если урл был /user/12345);
      • Делаем то, что от действия требуется: запускаем в космос ракету или отправляем сообщение таксисту на пейджер. Если нам нужны данные из БД, или если нам нужны данные с какого-нибудь Last.fm или твиттера, или еще какие-нибудь данные — любые вообще — просим о них модель. Если модель [пока] не умеет выдавать, просим так, будто умеет: $this->m->twitter->getUser(«va1ka»); или там $this->m->getUsersTable()->getUser(«va1en0k»); — как хотите, так и запрашивайте;
      • Выдаем view все, что он просил в шаге 3: $this->view->shachlo = «popyachtsa»; и т.п.;
    6. Дописываем в модель все, что мы у нее просили в предыдущем шаге.


    Этот алгоритм почти универсален (если нам нужно то, что происходит при любом действии юзера, надо действовать чуть по другому), и я рекомендую придерживаться его максимально четко. Почему сначала вид, а потом остальное? Ну, по двум причинам, во-первых, так советуют 37signals, а во-вторых, это самый разумный способ понять, что нам нужно и в каком виде получать. Важно следить, чтобы все запросы к данным шли только инкапсулированно через модель: тогда, о cчастье, мы сможем в случае чего махнуть не глядя базу данных на другую или добавить симпатичный кеш, ускоряющий нашу программу, как сброс ступенчатого модуля. Важно следить, чтобы весь HTML, ну, то есть, совсем-совсем весь, шел через находящееся в папках views или layouts, в хелперах или просто так.

    А теперь конкретнее по трём китам MVC.

    Вид

    Как я уже красноречиво намекнул, в Видах должен быть весь-весь HTML. Любые ошибки, что угодно, вот всё, что происходит в контроллере и — тем более — в модели должно быть лишено тегов и являться голой строкой. Любые константы вывода (я имею в виду, например, теглайны или «Ошибка! Имя юзера должно быть до 25 символов! Убей себя!») стоит тоже хранить во view.

    Как это cделать? На помощь спешат хелперы! Создаем хелпер (дальше идет удивительный код, который не факт, что стоит использовать as is, но, в принципе, в нем нет ничего совсем ужасного. Просто думайте сами, как хотите организовать происходящее):
    class Zend_View_Helper_Errors extends Zend_View_Helper_Abstract {
    	public function errors($err) {
    		if (!sizeof($err)) return '';
    		
    		$html = '<div class="errors">';
    		
    		foreach ($err as $er)
    			$html .= '<p>'. AppErrors::getErrorString($er) .'</p>';
    		
    		$html .= '</div>';
    		
    		return $html;
    	}
    }
    

    А также класс со статическим методом:
    class AppErrors {
    	static function getErrorString($er) {
    	  // возвращаем строку. Берем ее откуда-нибудь: массива там или БД или еще откуда-то, переводим, если надо, через Zend_Translate и возвращаем
    	}
    }
    


    Сам $err — аргумент хелпера — это массив «ошибок». Ошибка может кодироваться просто числом каким-нибудь, а может быть, и массивом, скажем, array( 'err_id' => 666, 'err_arg' => 'satan' ), если у ошибки есть аргументы %) Ну или вообще обьектом, у кого насколько фантазия извращена.

    Контроллер

    Контроллер состоит из действий. Действия — костяк (прям как в структурно-функциональной социологии на основе интеграционного подхода) приложения. Так вообще выглядит идеальный запрос от дизайнера программы к программисту: «Давай, если жать вот на эту кнопуську, будет происходить то-то». Вот, «то-то» это и есть действия (кому я это обьясняю?).

    Прежде чем плодить контроллеры пачками, я предлагаю сделать хитрый ход: создать наши собственный front и action контроллеры и наследовать уже от них. Тогда, в случае чего, мы сможем, например, запрещать посещение любых страниц без входа на сайт (как в лепрозории, например), выставлять разные нужные для экшн-контроллеров переменные и так далее:
    class SchachloFrontController extends Zend_Front_Controller {
    	// 
    тут не забываем перегрузить getInstance(), как доктор нам прописал
    } // не забудьте поменять bootstrap.php!
    class SchachloActionController extends Zend_Action_Controller {
    	// по-моему, ниче не обязательно перегружать %)
    } // и наследуем все экшн-контроллеры от него (это те, которые в /application/controllers/
    


    Ну, а дальше все более-менее понятно. Советую максимально расчленять код на мелких функции, пихая их в модель или оставляя на долю хелперов (как view helpers, так и action helpers). И не забывайте: любые данные стоит получать в model, даже отчество вашей бабушки %) Хотя не, его лучше в конфиг, если нужна только ваша бабушка.

    Модель

    С моделью, на самом деле, у меня больше всего сомнений по неопытности. Ну, я вот лично обычно делаю так:
    Для каждого типа данных создаю таблички в БД. Там для поста, для коммента, все дела. Если у типа данных есть переменная-массив (например, теги для поста), для него, ясен пень, отдельную табличку. Потом для каждой таблички создаю в /application/models/DbTable/ свой файлик. Ну и главный файлик — SuperModel.php — в котором наша прелестная Анжелина Джоли, возвращающая своими методами все таблички (которые у нее хранятся в статичных переменных). Аналогично, рядом пихаю нужные классы для работы с файловой системой или внешними источниками данных (недавно вот с last.fm работал, при помощи Zend_Rest_Client вообще без напряга), а в супермодель пихаю методы для их получения.

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

    Че еще сказать? Ах, да. Не забывайте про кеш. Можно добавлять в каждый метод слежку за кешем, а можно взять и сделать сразу 2 модели: одна будет такая, как описано выше, а другая будет сквозь кеш вызывать первую, заодно отключая его, когда он вообще не нужен. Я про кеш, наверное, еще напишу, если меня снова не забанят. :D

    Уф. Вроде 13 килобайт, а не особо много и рассказал. Любитель, чего уж тут! Жду ваших отзывов.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 135

      –21
      по мне так ZF неоправданно жрет много ресурсов проца
        +18
        да? ну ладно. удалю его со всех проектов. да лучше вообще их на Перле перепишу, вот это скорость, вот это мощь!
          –2
          о вкусах не спорят, но признаюсь перл мне по душе =)
            +10
            не спорю, у него есть плюсы :)

            давайте эта ветка будет единственной и последней веткой, в которой будет обсуждаться сам вопрос использования ZF. я пишу для тех, кто уже выбрал его ;) спасибо за ваше мнение
              0
              не знаешь, как вручную установить контроллер и акцию?
              я не могу использовать ссылки вида /module/controller/action/parameters
              у меня уже готовый сайт, и моё приложение выглядит как example.com/somepath/index.php?id=xxx
              но я могу добавлять любые get-параметры, и таким образом мог бы передавать controller и action:
              example.com/somepath/index.php?id=xxx&controller=somecontroller&action=someaction

              то, что мне нужно, это устанавливать в bootstrap контроллер и акцию вручную, из get-параметров, а потом уже запускать своё ZF-приложение

              пытаюсь разобраться с route, но пока безрезультатно
                0
                надо не со стандартным роутером колдовать, а свой писать. вам в помощь framework.zend.com/manual/en/zend.controller.request.html обьект запроса и дальше мануал
                  0
                  я эту страницу уже два дня читаю.
                  сделал проще:
                    function main($content, $conf) 
                    {
                    ...
                      $front = Zend_Controller_Front::getInstance()
                        ->setModuleControllerDirectoryName('controllers')
                        ->setControllerDirectory('mvc/application/controllers')
                        ->setDefaultControllerName('index');
                      $front->dispatch();
                    ...
                    }
                  ***
                    public function init()
                    {
                      $action = $this->_request->getParam('act');
                      if (method_exists($this, $action.'Action')){
                        $this->_forward($action);
                      }else{
                        $this->_forward('index');
                      }
                    }
                  

                  сейчас времени нет разбираться, потом ещё почитаю
            +1
            Давайте перепишем ZF на ассемблере ))
              0
              Не, ну на плюсах можно :) PHP ведь на плюсах :)
              Как раз то ли здесь, то ли на PHP форуме каком-то были подробные инструкции о том, как писать свои расширения к PHP на C++.
              Под высоко нагруженные проекты или просто часто используемые вещи можно и написать…
                0
                А можно как-нибудь поподробнее? Мне как раз нужно написать своё расширение для PHP!
            –4
            да? а в курсе сколько ресов жрёт обычный include или require? и учитывая портовость зенда — ну-ка, прикинь, что будет лучше — своя маленькая гибкая МВЦ или «три кита в ещё одном гипербольшом ките»?
              +3
              я серьезно абсолютно. каждому — своё. мне нравится ZF и я готов пару минут поколдовать с eAccelerator-ом и другими штуками ради веселого и простого кодинга. вам не нравится? окей, напишите свой фреймворк, придумайте что-нибудь еще — но не навязывайте мне своего мнения! пожалуйста
                0
                а если обьеденить все нужние файли в один;)?
                проверено, що include[_once] забирает какую-то там мимлсекунду.
                так зачем нужно тратить время на подгрузку всех необходимих файлов, если можно всю основную библиотеку класов собрать в один файл? при етом время ускоряется до 22-х раз… Статья Дмитрия Котерова: dklab.ru/chicken/nablas/49.html
                  0
                  А зачем нужна маленькая «МВЦ»? Для маленьких сайтов-визиток? При создании проекта покрупней эта «маленькая» обрастёт кучей… кода, и станет головной болью. Уж лучше Zend, где есть некоторая избыточность, но именно она обеспечивает хорошую гибкость и конфигурируемость MVC-инфраструктуры.
                    0
                    а «маленькая» не может быть гибкой и конфигурируемой?
                      0
                      Нет, не может. Чем гибче система за счёт конфигурируемости — тем она сложнее внутри. Т.е. гибкость и простота — вещи несовместимые. ZF как раз сложная и гибкая система.
                        0
                        маленькая и простая помоему не одно и тоже, просто зенд весит 10 метров без локалей, помоему это многовато для «платформы», он конечно не задействует неиспользуемые модули, но тем не менее размер удручает морально
                          0
                          Если Zend вас морально подавляет — используйте CodeIgniter.
                        0
                        На мой субъективный взгляд, это классическое заблуждение, которое и побуждает многих писать свои фреймворки и CMS с нуля.
                      0
                      А использовать акселераторы уже не модно? Затраты на include закешированного акселлератором скрипта — ноль миллисекунд.
                      +1
                      Да, ZF перегружен кодом, это плата за 1) возможность взаимоменяемости компонентов (посмотрите например на код для работы с БД, ) 2) попытку сделать универсальный фреймворк.

                      Да и одни названия классов по 30 символов чего стоят… брр… проще надо.

                      Возвращаясь к DAL в ZF — нагородили кучу кода, и что? Даже нормальной работы с плейсхолдерами нет, то есть надо поверх всего этого еще совй код писать, получается в результате монстр.
                      0
                      А вы будете дома на 600 селероне размещать крупный проект? Да и как говорилось, кеширование спасает всю ситуацию.
                        +1
                        Небольшой VPS вполне сравним с таким селероном.
                          0
                          Тот же magento может привалить простой VPS, но это не значит, что он плохой. Но даже хабр, на самописном работает, так что везде свое.
                      • UFO just landed and posted this here
                          0
                          а может Вы его просто использовать не умеете?
                          0
                          не забанят…
                            +1
                            * rouses.php [1]
                            Поправь плиз на routes.php
                              +2
                              как романтично :'|
                              –20
                              "(часов за 6 легко делается без особого напряга набор авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем"

                              не вижу смысла тратить на такую мелочь целых 6 часов.
                                +20
                                да вообще, челябинские мужики делают сервер за минуту на перле
                                  +3
                                  Челябинские мужики намного суровей…
                                  Они делают сервер за минуту; о)
                                  +7
                                  Сейчас еще любители джумлы припрутся.
                                    0
                                    джумла не даст такой гибкости) проверено)
                                    –3
                                    сразу видно кто юзает зенд — тот отчаянно минусует ;)) хомячки

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

                                    лично я попытался и написал свою МВЦ, которая поместилась дай бог в несколько килобайт.
                                    Ну да там нету миллиона optional пакетов, зато есть гибкость и легкость построения, на которой остался настоящий принцип МВЦ, без лишнего мяса и миллиарда ненужных проверок.

                                    давайте-ка вспомним сколько всего нужно чтобы сделать обычную форму в зенде. И это, вы скажете, «гибкая система»?

                                    в общем я хотел лишь сказать, что «суровые» кодеры юзают сторонние фреймворки, а «свою крепость строить даже не пробовали»
                                      +1
                                      Согласен с тобой.
                                      Свой фреймворк — вещь хорошая.
                                      Но как-то совпало так, что я сейчас учу ZF и это статья именно о нем. Когда я пойму в чем соль ZF, что в нем хорошо, что плохо — напишу свой, мелки, но сочни фреймворк.
                                        +1
                                        никто не запрещал использовать отдельние компоненти ZF в своих приложениях… они легко подключаются ж не создавая никаких трудностей)
                                          +1
                                          Я собираюсь писать свой фреймворк для того, чтоб не зависеть ни от кого.

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

                                          А еще это будет большим плюсом при трудоустройстве куда угодно.
                                            +1
                                            Нет, не будет. По крайней мере — не куда угодно.
                                              +2
                                              Читая чужой код Вы получите гораздо больше опыта, чем если бы Вы сами придумали несколько реализаций одной задачи. Проверенно. Тем более код таких монстр-программеров.
                                              P.S. Не читайте код вордпресса, во избежание взрыва мозга :-)
                                                +1
                                                Хехе :)

                                                Но есть мнение, и не только мое, что теория без практики мертва. А чтение кода, без его написания — разве не теория? ;)

                                                И да, придумывание своих реализаций задачи только развивает мозг, что вовсе неплохо, не так ли? :)
                                                  +3
                                                  Ну удачи Вам в изобретении велосипедов.
                                                  По вашей теории оставаться надо было на ассемблере и не повышать уровень языков, развивая мозг придумыванием алгоритмов под него.
                                                  Фреймворк это повышение уровня языка, да он требует большего, но и сервак с 4 гигами оперативы и четырёхядерниками уже обычное дело.
                                                    +2
                                                    Уважаемый, я просто поделился своими планами на будущее.

                                                    Моя теория — это развитие мышления. А это дело глобальное, оно не ограничивается языком или фреймворком.

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

                                                    Взаимно желаю добра и плюсую Ваш пост :)
                                                      +1
                                                      я конечно жутко извиняюсь, но и сейчас есть люди, которые пишут и под асм и под си… Системщиками их кличут… Просто разные направления деятельности. Более того, взгляните на ситуацию в геймдеве — там часто пишут новые движки, хотя можно использовать чужие.
                                                      И да, своя рубашка ближе к телу.
                                                      ЗЫ. все это имхо
                                                      0
                                                      Изучение чужого кода ближе к практике, чем к теории. Ведь мы изучаем конкретное решение, а не какие-то общие понятия.
                                                        0
                                                        Когда-то я тоже проходил через стадию «Напишу своё, чтобы набраться опыта» и считаю это очень полезным для «развития мозга». Это полезно, когда учишься. Я много чего понял, когда писал свой фрэймворк на основе теории из книг «Design Patterns: Elements of Reusable Object-Oriented Software» и «Patterns of Enterprise Application Architecture». И я не жалею, что сидел и изобретал колёса в то время.

                                                        А сейчас я предпочитаю использовать готовые решения, такие как ZF, потому что они заметно ускоряют скорость и качество разработки. К тому же, так как я многое узнал, пока изобретал велосипеды, я понимаю бОльшую часть логики, на основе которой построен ZF.

                                                        Поэтому, считаю, вопрос не в том, какой из подходов — изобретать велосипед или использовать готовые решения — лучше, а в том, что для Вас является важнее — обучение или быстрая разработка проекта.
                                                +6
                                                Я написал на досуге свою MVC за 2 часа — там и контроллер запросов, и экшны, и шаблоны. Просто для прикола. Немного файлов, несколько килобайт. Для тренировки может быть полезно, но на практике бессмысленно — лучше использовать готовую реализацию из какого-либо фреймворка.

                                                MVC в Zend гибок, в работе не раз убеждались. Можно управлять и представлением, и роутингом и многим чем ещё — используя написание своих, отнаследованных классов, плагины и т.п.

                                                Формы — отдельный разговор. Делать формы «от руки» я бы не сказал, что проще. А валидация? А подстановка значений?

                                                Одно дело, когда разработчик пишет сам, потому что имеющихся решений объективно не хватает (но он их изучил), другое — когда страдает синдромом «сделано не здесь» или считает себя самым умным.

                                                Конечно, хорошо, когда человек начал путь в разработке с написания своей мегапростой и мегаудобной и производительной CMS — сделать не сделает, но чему-то научится. Но изучение на первых порах фреймворка, думаю, не менее (а может быть и более) полезно при правильном подходе. Исходные коды ZF хороши как образец того, к чему можно стремиться.
                                                  0
                                                  не путайте мвц за 2 часа и готовый фреймверк, пусть и самописный, ваши 2 часа и в подметки не будут годиться «маленькому» фреймверку, и то что Вы перечислили из преимуществ у зенда, в любом самописном фреймверке реализовано:
                                                  роутинг — первостепенная реализация (как минимум урл разобрать в дефолт)
                                                  фронт контроллер — надо ведь откуда-то начинать работу фреймверка
                                                  вью — один интерфейс и любой шаблонизатор можно подключить
                                                  наследование не зависит от фреймверка, да и формы можно повторить… эти вещи есть везде
                                                    0
                                                    «Любой самописный фреймворк» — интересное обобщение. Вы точно отвечаете за свои слова?
                                                      0
                                                      мвц фреймверк обязан (я так считаю) соответствовать требованиям перечисленным выше
                                                  +3
                                                  Мммм, всегда считал MVC (Model-View-Controller) паттерном проектирования/программирования…
                                                  Причему тут все, что Вы написали, я не понимаю…
                                                    0
                                                    человек имел ввиду «фреймверк», могли бы и подиграть :)
                                                    0
                                                    Делал это дважды. Сначала свой собственный велосипед, потом еще обвес для такого кошмара как DJEM. В результате, обнаружил, что начал дублировать функционал зенда. В данный момент разрабатываю именно на нем)
                                                      0
                                                      странно, вот передо мной мвц самописная, и тут отнюдь не несколько килобайт, в вашей мвс были роутеры? перехват ошибок с последующей отдачей пользователю? любой темплейтовый движок можно было подключить без проблем? и + бд уже дотянет до полуметра, так это лишь вершина айсберга для «гибкости и легкости построения»…
                                                      зы: в ZF формы делаются на ура, один обьект = одно поле, добавил в форму, и все! проверка валидности одной строчкой (isValid) так же по одной строчке на валидаторы для поля… не вижу ничего страшного в этом — «как 2 пальца»
                                                      вот Вы попробуйте настроить на своей мвц роутер на пути
                                                        0
                                                        … тут мысль обрывается :( не ту кнопку нажал
                                                    0
                                                    Кому ресурсы, а кому удобство. Если надо, что бы быстро, то действительно на перле или на сях надо писать. Только вот потом с вопросами «а не дописать ли нам чего-то там, да так что б быстро, и так что б 50 других девов разобрались..» лучше не приставать.
                                                      +3
                                                      Интересный стиль изложения материала :)
                                                      Мне понравилось читать!

                                                      Что ZF — да, он хорош, гибко, масштабируемо и доступно.
                                                      Впрочем как и сам PHP
                                                        +2
                                                        И мне понравилось. И ZF нравится, пишите больше :)
                                                        +4
                                                        согласен с va1en0k, ZF удобная и хорошая вещь. Я потрали как-то небольшое колличество времени, и сделав удобную структуру, добавив свои классы, переписав для себе (точнее дополнив) Zконтроллер и Zaction получил каркас, который теперь с легкостью использую в проектах. При этом все влитает очень быстро, так что на выходе получаю результат и малое колличество проблем.
                                                          –4
                                                          оффтоп, не пинайте больно, изучаю в данный момент рельсы, так вот перечисленное делается на рельсах не за 6 часов, а за меньше часа…
                                                            +2
                                                            Хотел бы я посмотреть, как Вы это сделаете за час. Полуготовое тяп-ляп решение без тестов же сделанным не считается?
                                                              0
                                                              в рельсах система тестирования встроена, тесты там пишуться тоже просто и легко.

                                                              И не надо ругаться, посмотрите лучше, я сам был очень удивлен насколько быстро и просто. Опять же говорю что я лично в рельсах новичек как незнамо кто, и почемуто даже у меня получается все быстро.
                                                                0
                                                                Вообще-то я программист на rails :)
                                                                Может просто я тормоз, но мне слабо представляется, как я вот так сходу за час это сделаю.
                                                                  +6
                                                                  авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем
                                                                  — авторизация+регистрация — script/plugin install restful_authentication
                                                                  посты+лента+комменты — ну это уж точно Вы в рельсах сделаете за пять минут script/generate model…
                                                                  древовидность загоняем в модель (добавляем у коммента ссылку на себя)

                                                                  и всё, потом быстренько правим .html.erb что нагенеирровались по умолчанию, и меньше чем за час управляемся с описанной задачей.
                                                                    +2
                                                                    если совсем лень то для деревьев можно поставить плагин вроде acts_as_tree…
                                                                    +3
                                                                    дайте мне кармы и я покажу в посте как я сделаю за час пользователей, авторизацию, посты, древовидные коменты и ленту на рельсах :)

                                                                    зачем минусовать когда есть способ всё показать и объяснить? :)

                                                                    кстати ничем не умоляет ZF, очень мощная система, рельсы наверное попроще будут…
                                                                      0
                                                                      подкинул кармы. жду пост, ну или в личку)
                                                                        0
                                                                        ок, катаю пост, отпишу в личку как сделаю, думаю на пост уйдет не намного больше времени чем я сказал выше. Начал в 21:00 по москве. Пуск.
                                                                          0
                                                                          весь в предвкушении. секундомер запущен
                                                                            0
                                                                            да, печатаю я медленно, но зато я все что писал проверял, можно смотреть в моём личном, все что я написал сделал за полтора часа, остальное потратил на исправление мелких ошибок.
                                                                              0
                                                                              так, я уматываю, до дому, закончу оттуда. По ощущениям, на написание кода (а не статьи) потрачено гдето 20 минут времени
                                                                            0
                                                                            простите что влезаю, но мне тоже жутко интересно

                                                                          +2
                                                                          До того как прочитал ваш комментарий про 1 час, подумал то же самое про Django :)
                                                                          Конечно, так торопиться не стоит, но по-моему это гораздо более приятная штука, чем ZF.
                                                                          Рельсы тоже хороши, но тут уже вопрос личных предпочтений. Вообще не стоит ограничиваться языком программирования, многие разработчики на Django и RoR прежде не писали на питоне и руби, но это не проблема, можно освоить достаточно быстро в процессе.
                                                                            0
                                                                            я не специалист в джанго, не специалист в RoR, если в Django всё настолько же просто, связно, понятно и логично как в RoR, то я снимаю шляпу :) смотрю на эту статью по ZF и понимаю — что ZF более открыто позволяет делать сложные вещи, но для простых вещей приходится делать лишнюю работу.
                                                                              0
                                                                              У меня тоже сложилось такое впечатление.
                                                                                +1
                                                                                собственно статью накатал, в сумме кодинга получилось даже меньше чем на час, больше времени убило написание самой статьи :)
                                                                +1
                                                                Очень хочется увидеть подробный туториал «авторизация+регистрация+посты+лента+древовидные комменты».
                                                                Если такой где-то есть в интернетах (а я уверен, он есть) не ставьте мне минусик, а киньте ссылку, пожалуйста.
                                                                  +3
                                                                  в следующей части, наверное, будет про Zend_Auth, там про первые два пункта

                                                                  а посты, ленту — ну это в любом туториале почти можно найти, или даже самому придумать
                                                                  с комментами чуть посложнее, но я о них тоже обязательно напишу, ну, если дойдет до 3-4-итакдалее частей :)
                                                                  0
                                                                  кто-нибудь знает, как запихать диспетчера Zend_Controller_Front::getInstance()->dispatch()
                                                                  в main()-функцию расширения typo3?
                                                                  хотелось бы иметь нормальную структуру ZF-приложения под typo3.

                                                                  пока у меня получилось установить автолоадер (расширением) и подключить Zend_View, но хотелось бы всех ништяков MVC от ZF. сижу вот правлю Zend_Controller_Dispatcher_Standard
                                                                    0
                                                                    А кто-то может внятно объяснить, зачем во всем ZF насильно пишутся require 'blablabla.php', всодя на нет все возможности автолоада, упаковки ядра в один файл и тд и тп?
                                                                      +1
                                                                      потому что не всем по душе Zend_Loader
                                                                      а упаковать ядро в один фаил это не мешает, надо только вычистить их, м? ;)
                                                                        0
                                                                        короче, снова обработать напильнегом… ага, знаем…
                                                                          +2
                                                                          Zend построен по принципу «use at will» — у него нет «ядра», а упаковывать его целиком в один файл — то ещё извращение.
                                                                          Достаточно юзать нормальный кэш опкода и не экономить на спичках.
                                                                            –3
                                                                            расскажите это своей бабушке.
                                                                            выигрыш в скорости с eAccelerator — в 2-3 раза
                                                                              0
                                                                              Чукча не читатель?
                                                                              eAccelerator == «нормальный кэш опкода»
                                                                      +1
                                                                      А можно сорцы вашего приложения выложить куда-нибудь для скачивания? Хотелось поближе посмотреть…
                                                                        +2
                                                                        сорцы чего? :) «скелета»? хм, давайте тогда попробую их подготовить и в следующую «главу» закину
                                                                          0
                                                                          Ну не скелета уж… Я про «авторизация+регистрация+посты+лента+древовидные комменты+чай+кофе+потанцуем» или что-нибудь подобное
                                                                            0
                                                                            нет, не выложу. готовые выкладывать не хочу, а писать специально для — лениво ;)
                                                                          0
                                                                          zendframework.ru/articles/tutorial-building-basic-site-on-zend-framework-1-5 поиск по слову «Заключение»
                                                                        • UFO just landed and posted this here
                                                                            +3
                                                                            я, кстати, первым делом однажды прикрутил к ZF смарти

                                                                            потом уже осознал, что смарти — бессмыслица :) Zend_View отлично справляется сам по себе
                                                                            • UFO just landed and posted this here
                                                                                +4
                                                                                почитайте Смирнова: spectator.ru/technology/php/easy_templates — он, в общем, во многом сформировал такое мое мнение :)

                                                                                ну да ладно, не хочу холиваров. я же не занимаюсь антипиаром смарти, чтобы доказывать, что он не нужен — мне за это не платит никто 8)))
                                                                                • UFO just landed and posted this here
                                                                                    0
                                                                                    А php-шаблоны — не компилируемые? Аксселераторы байт-кода не в счет?
                                                                                    Я не спорю, мне правда интересно.
                                                                                    • UFO just landed and posted this here
                                                                                        0
                                                                                        Мне казалось, автор коммента выше говорил о компилируемости в контексте скорости, а не удобства для верстальщиков-неучей.

                                                                                        Видимо, мне повезло — все верстальщики, с которыми я работаю, не настолько ленивы, чтобы не быть в состоянии выучить 5-10 простых конструкций на php, выполняющих функции, совершенно аналогичные приведенным вами.
                                                                                        • UFO just landed and posted this here
                                                                                          0
                                                                                          Вы бы изучили возможности ZF поглубже, особенно Zend_Layout и view helpers — очень может быть, что возвращаться к Smarty пропадет всякое желание.

                                                                                          Кстати, в тех компаниях, где доводилось работать мне, верстальщики никогда не верстали непосредственно шаблоны — они верстали «мёртвые» HTML-ки, которые девелоперы потом «оживляли» при помощи того шаблонизатора, с которым им комфортнее работать.
                                                                                          • UFO just landed and posted this here
                                                                              0
                                                                              Ура. Дождались.
                                                                              Про всю чушь уже написали мензурки-коробки и прочие части.
                                                                              Наконец и про ZF!
                                                                                0
                                                                                Спасибо за обзор ZF, как раз на днях решил, что стоит переделать свою небольшую CMS под него, теперь разбираться, думаю, будет чуть проще. Конструктивно: понравилось описание контроллера, согласен с мыслью что «в Видах должен быть весь-весь HTML», релизация тут уж как кому нравится, а вот модель я думаю можно сделать поинтереснее, для отражения составных иерархический сущностей, хотя в большинстве случаев такого варианта будет достаточно. К стати, должно все работать быстро, так как архитектура фреймворка простая, компоненты маловзаимозависимы, что хочеш, то и используй как больше нравится, помоему шикарно. Что-то я сильно сомневаюсь, в том что те у кого «тормозит» смогут показать мне свою более-мение внятную php альтернативу ZF.
                                                                                  0
                                                                                  расскажите про модель, пожалуйста, подробнее, м? ;)
                                                                                  +1
                                                                                  мне показалось, что то что написано в статье новичку ЗФ непонять никак, а те кто поймут, уже всё это знают. Будьте немного помягче с читателем. А так я бы с удовольствием почитал продолжение, только мне кажется не стоит писать про Auth блоги и тд. потому что на хабре уже была такая статья и даже не одна. в самом начале с тех пор ничего не изменилось вроде сильно в этих вопросах.

                                                                                  Я бы с удовольствием почитал о рациональном использовании ЗФ, потому что чувствую во многих моментах себя быдлокодером (
                                                                                    0
                                                                                    Кстати, я совершенно случайно пару дней назад искал реализованный каркас, чтобы почерпнуть новые мысли по эффективной разработке на базе ZF. Тут некоторые спрашивали исходники. Ну и пока автор статьи подготавливает их, особо нетерпеливым предлагается «поковырять» довольно свежее opensource решение, естественно на базе ZF: Digitalus CMS.

                                                                                    Порадовало, что в отличии от, например, тяжеловесного Magento, в вышеназванном приложении всё довольно просто и лаконично, без диких цепочек наследований и туманной реализации EAV. Рекомендую обратить внимание на pageBuilder. В общем нетерпеливым продуктивного изучения, а от автора ждём скорого продолжения :)
                                                                                      +1
                                                                                      О подробностях БД-части модели хотелось бы отдельную статью. С использованием Zend_Db и разных хитрых типов связей таблиц.
                                                                                        0
                                                                                        Поддерживаю комментарий, или в ZF довольно слабая (по беглому изучению документации + небольшой опыт использования) работа с моделью, или одно из двух )) Хотелось бы увидеть связи таблиц.
                                                                                          +1
                                                                                          Нет связей. Модель в ZF как бы и не совсем модель. То-есть она не совсем ORM. Дело в том, что в большинстве случаев Zend_Db вполне хватает. А хотите наворотов — прикрутите Doctrine
                                                                                        0
                                                                                        жду продолжения.
                                                                                          +2
                                                                                          Статья хорошая, спасибо вам.

                                                                                          Немного критики, если позволите :)

                                                                                          Вместо хелперов типа "<?=$this->printUser($this->user)?>", часто бывает удобнее использовать механизмы типа view helper'а partial — иначе придется генерировать много HTML-кода внутри хелпера, конкатенировать его в строку и т.д., а мне это кажется неудобным.

                                                                                          Кроме того, называть собственные классы с префиксом Zend (типа Zend_View_Helper_Errors) — это моветон.
                                                                                          Создайте собственную директорию внутри library, выберите себе префикс по вкусу и называйте классы, например, Super_View_Helper_Errors, складывая их в library/super/view/…
                                                                                          Конечно, в данном конкретном случае, нужно будет отдельно добавить эту директорию в настройки View (к примеру, в бутстрапе) при помощи $view->addHelperPath('/my/cool/project/library/super/view/helper', 'Super_View_Helper').
                                                                                            +1
                                                                                            Спасибо, да. Первое я как-то пропустил, со вторым тупанул :)

                                                                                            Вторую часть придется начинать с работы над ошибками
                                                                                              0
                                                                                              Скоро появятся настоящие namespace в PHP, будет проще в этом отношении.
                                                                                              +2
                                                                                              Привет, va1en0k! Мы рады, что ты вернулся :)
                                                                                                0
                                                                                                ха-ха, а мы-то как рады ;))
                                                                                                +3
                                                                                                Несмоторя на то что дочитал до конца (ну это правдо из за того что есть большое желание хорошо въехать в ZF), всякие выражения и названия классов к стиле «упячки», очень отбивали желание продолжать делать это (дочитывать до конца), и хотелось все закрыть и заминусовать… Но несмотря на это, спасибо за статью, и жду следующею, надеюсь без этих выражений…
                                                                                                  +1
                                                                                                  а другим наоборот понравилось
                                                                                                  в любом случае, стиль менять не буду, минусуйте сколько хотите. мне за это никто не платит :3
                                                                                                  0
                                                                                                  простите, но URL вида /post/12321 надо будет обрабатывать через preDispatch() контроллера, я так понимаю? (при условии, что post — это имя контроллера, на что указывает абсолютный адрес). ну или придеться писать роуты для всего этого добра — было бы интересно прочитать именно о них, страшно я ленив, что бы доки читать :)
                                                                                                  спасибо
                                                                                                    0
                                                                                                    URL обрабатывается с помощью роутов и если мы использовали роут, например, 'post/:post_id/*', то в контроллере мы сможем с помощью $this->_getParam('post_id') получить этот параметр.
                                                                                                    При этом совсем необязательно, что бы имя контроллера совпадало с post. Модуль, контроллер и экшен — это всё указывается в настройках роута.

                                                                                                    Один из роутов, используемый в нашем проетке, выглядит так:
                                                                                                    new Zend_Controller_Router_Route('user/:login/:action/*', array('module' => 'default', 'controller' => 'user', 'action' => 'index'));

                                                                                                    Если нужны объяснения — спрашивайте :)
                                                                                                    +2
                                                                                                    стиль повестоваавания поста понра!
                                                                                                    продолжайте в том же духе — спасибо (:
                                                                                                      +4
                                                                                                      Сразу видно влияние Лепры на автора :)
                                                                                                        0
                                                                                                        1. перегружать Zend_Action_Controller и Zend_Front_Controller зачастую не нужно. Зенд предлагает для упомянутых задач использовать плагины.

                                                                                                        2. Отказываться от Zend_Form не обязательно. Вы не учитываете что помимо генерации верстки это еще и весьма удобный механизм компоновки валидаторов, фильтров, метаданных относящихся к форме. Zend_Form вообще не заставляет вас выводить форму. Лично мне работать с формой как с объектом бывает весьма удобно. Хотя при сложных дизайнерских формах конечно проще будет ее верстку написать руками. Подробнее свою позицию изложил тут.

                                                                                                          0
                                                                                                          2. Тяжеловаты примеры. Дело в том, что цель сделать «легкодорабатываемое» приложение, а использование Zend_Form тут же прячет от нас генерацию html-кода или заставляет расписывать его вот как-то так, как там у вас, да?
                                                                                                          <?php echo $this->formRegister->name->getLabel(); ?>
                                                                                                          <input 
                                                                                                              type="text" 
                                                                                                              name="<?php echo $this->formRegister->name->getName(); ?>" 
                                                                                                              value="<?php echo $this->formRegister->name->getValue(); ?>" 
                                                                                                              maxlength="<?php echo $this->formRegister->name->getAttrib('maxlength'); ?>"
                                                                                                          />

                                                                                                          Окей, по-моему, это не круто ;-) От Zend_Form будет трудно резко отказаться уже потом, когда все уже сделано на нем, а использование его превращается в кропотливую работу, ну, как мне кажется

                                                                                                          1. Спасибо, я посмотрю еще раз. Не помню, почему от них отказался. Когда я впервые субклассировал фронт_контроллер, был еще зф 1.5.0 и что-то там нужное мне не работало (или я просто не разобрался, возможно, так)
                                                                                                            0
                                                                                                            Выше я написал что генерацию верстки можно не делать. Но это не значит что нужно полностью выбросить Zend_Form, в любом случае придется писать какой то свой механизм обработки ошибок к примеру.

                                                                                                            А чем пример тяжеловат, ну допустим метку можно вывести еще руками.
                                                                                                            а name, value, maxlength это явно не забота верстальщика. И хорошо если эти параметры можно настраивать из одного места.

                                                                                                            Если очень хочется можно упростить даже до такого
                                                                                                            <iinput 
                                                                                                                type="text" 
                                                                                                                name="email" 
                                                                                                                value="<?php echo $this->formRegister->name->getValue(); ?>" 
                                                                                                                maxlength="20"
                                                                                                            />
                                                                                                            


                                                                                                            Проще этого не будет даже если вы будете делать полностью руками.
                                                                                                              0
                                                                                                              ну что ж, возможно, так действительно удобнее для вас. я отказываюсь от зенд_форм чисто сам по себе, никого не агитирую делать так же :) спасибо за ответы, надо будет поизучать пристальнее, вдруг проникнусь
                                                                                                          0
                                                                                                          Так я вот подумали изменил свою точку зрения насчёт того, что статьи типа «написание блогового движка» не нужны. Мне кажется что всё что я читал ранее было написано немного недобросовестно. Всего по чуть чуть и в итоге ничего серьёзного. Вот если кто-то возьмётся написать такую статью, где будет всё грамотно и полно описано, так чтобы придраться не было возможности, то цены такой статье не будет, хотя возможно договоримся)) На пример одного модуля или контроллера рассказать о ЗФ так, чтобы дальше любой другой модуль не вызывал никаких трудностей и при этом чтобы была уверенность, что Зенд используется наиболее эффективно. По-моему это вполне реально написать и многим поможет
                                                                                                            0
                                                                                                            Есть такая статья, правда, не одна, а серия. Здесь первая часть.
                                                                                                              0
                                                                                                              Вряд ли этот туториал претендует на звание «придраться нет возможности»
                                                                                                              В целом считаю в любом объемном труде будет авторский стиль, который другим может не подходить.
                                                                                                                0
                                                                                                                В отличие от многих авторов подобных туториалов, Padraic Brady реально участвует в разработке ZF, и уж кому, как не ему знать, как эффективно и идеологически правильно использовать данный фреймворк.
                                                                                                                  0
                                                                                                                  Я его весьма подробно прорабатывал в свое время. Он хорош, но не идеален, и не совсем для полных новичков. Padraic Brady один из большой команды, со своим мнением, хотя здесь framework.zend.com/community/contributors, о нем почему-то забыли. К примеру в некоторых моментах его подход отличается от подхода Matthew Weier O'Phinney, который является разработчиком ZF еще в большей мере.
                                                                                                            0
                                                                                                            А я чего-то не понял. Продолжение-то ждать? Или рыдать и колоться самому? :)

                                                                                                            Only users with full accounts can post comments. Log in, please.